Loading ...
Sorry, an error occurred while loading the content.

Re: [soaplite] keep alive

Expand Messages
  • Philip Molter
    ... Well, considering that SOAP::Lite uses LWP::UserAgent for its transport, probably not. I may be wrong, but I don t think LWP::UserAgent supports HTTP
    Message 1 of 11 , Apr 4, 2001
    • 0 Attachment
      On Wed, Apr 04, 2001 at 11:04:53AM -0400, Mathieu Longtin wrote:
      : Is there a way to send multiple requests on the same http connection? Using
      : SOAP::Lite of course.

      Well, considering that SOAP::Lite uses LWP::UserAgent for its
      transport, probably not. I may be wrong, but I don't think
      LWP::UserAgent supports HTTP keep-alive (at least, that's been my
      experience with it). We wrote a little custom HTTP transport agent for
      an other XML-RPC app that we wrote in-house. It's worlds faster.

      * Philip Molter
      * DataFoundry.net
      * http://www.datafoundry.net/
      * philip@...
    • Paul Kulchenko
      Hi, Mathieu! ... If you redirect output somewhere (/dev/null or other file): perl Makefile.PL /dev/null it s smart enough to take default values and create
      Message 2 of 11 , Apr 4, 2001
      • 0 Attachment
        Hi, Mathieu!

        > is there a way to build SOAP::LIte with no user intervention?
        > I need that for an install script, and it calls for minimal user
        > input...
        If you redirect output somewhere (/dev/null or other file):

        perl Makefile.PL >/dev/null

        it's smart enough to take default values and create makefile with
        them. Then just run make, make test, make install, it doesn't require
        user intervention. It should help.

        Best wishes, Paul.

        --- Mathieu Longtin <damnfrenchy@...> wrote:
        > is there a way to build SOAP::LIte with no user intervention?
        >
        > I need that for an install script, and it calls for minimal user
        > input...
        >
        > Thanks
        >
        > -Mathieu
        >


        __________________________________________________
        Do You Yahoo!?
        Get email at your own domain with Yahoo! Mail.
        http://personal.mail.yahoo.com/
      • Paul Kulchenko
        Hi, Philip! ... I don t think so either. I ve added patch that makes it work with server that returns keep-alive connection (it died on timeout before), but
        Message 3 of 11 , Apr 4, 2001
        • 0 Attachment
          Hi, Philip!

          --- Philip Molter <philip@...> wrote:
          > Well, considering that SOAP::Lite uses LWP::UserAgent for its
          > transport, probably not. I may be wrong, but I don't think
          > LWP::UserAgent supports HTTP keep-alive (at least, that's been
          I don't think so either. I've added patch that makes it work with
          server that returns keep-alive connection (it died on timeout
          before), but looking in the code it still closes the connection
          (though it may be changed). At the same time it's socket
          manipulation, so probably it's something that can be fixed. It's not
          my field, but given some advices I can try to do it.

          > experience with it). We wrote a little custom HTTP transport agent
          for
          > an other XML-RPC app that we wrote in-house. It's worlds faster.
          Is it in Perl? Is it something you want to share?
          Speaking about XML-RPC, next version will include XMLRPC::Lite with
          SOAP::Lite interface, but XMLRPC payload. It was tested with
          userland's validator and it works just fine (for the first version).
          It gives you access to all features of SOAP::Lite (authentication,
          compression, SSL support, etc), access to all transports, and works
          on client and server side. Will it be interesting?

          Best wishes, Paul.


          __________________________________________________
          Do You Yahoo!?
          Get email at your own domain with Yahoo! Mail.
          http://personal.mail.yahoo.com/
        • Philip Molter
          ... It is in Perl, but this company has a strict non-disclosure policy. It s really a very simple module, though. Basically, send the keep-alive, and don t
          Message 4 of 11 , Apr 4, 2001
          • 0 Attachment
            On Wed, Apr 04, 2001 at 09:02:36AM -0700, Paul Kulchenko wrote:
            : Is it in Perl? Is it something you want to share?

            It is in Perl, but this company has a strict non-disclosure policy.
            It's really a very simple module, though. Basically, send the
            keep-alive, and don't close the socket until you get a request for a
            new site. The thing is, it's written for a very special case for some
            quick machine monitoring we're doing. It doesn't implement nearly the
            number of features that LWP does (no SSL, very little configurability,
            etc.).

            : Speaking about XML-RPC, next version will include XMLRPC::Lite with
            : SOAP::Lite interface, but XMLRPC payload. It was tested with
            : userland's validator and it works just fine (for the first version).
            : It gives you access to all features of SOAP::Lite (authentication,
            : compression, SSL support, etc), access to all transports, and works
            : on client and server side. Will it be interesting?

            That's going to be very nice to have.

            * Philip Molter
            * DataFoundry.net
            * http://www.datafoundry.net/
            * philip@...
          • Robert Barta
            ... OH, YES! One issue I will have in the next future is: speed. Currently SOAP::Lite is using Expat, which is stable and working. But in the case of SOAP and
            Message 5 of 11 , Apr 4, 2001
            • 0 Attachment
              > : Speaking about XML-RPC, next version will include XMLRPC::Lite with
              > : SOAP::Lite interface, but XMLRPC payload. It was tested with
              > : userland's validator and it works just fine (for the first version).
              > : It gives you access to all features of SOAP::Lite (authentication,
              > : compression, SSL support, etc), access to all transports, and works
              > : on client and server side. Will it be interesting?

              OH, YES!

              One issue I will have in the next future is: speed.

              Currently SOAP::Lite is using Expat, which is stable and working. But
              in the case of SOAP and XML-RPC the payload format is not completely
              arbitrary but has a rather predictable syntax.

              I'm sure that a "SOAP-XML" or "XML-RPC-XML" parser can be considerable
              faster than the generic Expat.

              Any ideas (a) which parser to use and (b) how to tell SOAP::Lite to use
              it?

              \rho
            • Paul Kulchenko
              Hi, Robert! ... Actually you ll be able to specify any parser (SOAP::Lite has SOAP::Serializer which has SOAP::Parser which refers to XML::Parser). You may
              Message 6 of 11 , Apr 4, 2001
              • 0 Attachment
                Hi, Robert!

                > Any ideas (a) which parser to use and (b) how to tell SOAP::Lite to
                > use it?
                Actually you'll be able to specify any parser (SOAP::Lite has
                SOAP::Serializer which has SOAP::Parser which refers to XML::Parser).
                You may insert your parser in any plca of this chain and in fact next
                version will be shipped with regexp-based XML parser that can be used
                instead of XML::Parser (it'll be used automatically or you may
                specify it explicitly).

                But the main problem is not in parser's speed. Result of parsing is
                represented as Perl data structures and that part affects
                performance. Just try to specify Style = 'Tree' (similar to what I
                have) for XML::Parser and you'll see the difference.

                I was even thinking about do NOT parse the whole message, just
                extract the information about method and parameters and represent
                them as tied variable, so as soon as you need it, I'll use XPath or
                something like that and will get you value, but I don't think that
                it'll be really benefitial. The problem is that if you get request
                with parameters a, b, and c that basically means that you'll need all
                of them and there is no value in delaying parsing. I'm moving toward
                internal infrastructure that will let you specify streamin
                processing, but it won't work with MIME messages and with
                XML::Parser::Lite (I need to have whole message before parsing it).

                Any comments and ideas are greatly appreciated.

                Best wishes, Paul.

                --- Robert Barta <rho@...> wrote:
                > > : Speaking about XML-RPC, next version will include XMLRPC::Lite
                > with
                > > : SOAP::Lite interface, but XMLRPC payload. It was tested with
                > > : userland's validator and it works just fine (for the first
                > version).
                > > : It gives you access to all features of SOAP::Lite
                > (authentication,
                > > : compression, SSL support, etc), access to all transports, and
                > works
                > > : on client and server side. Will it be interesting?
                >
                > OH, YES!
                >
                > One issue I will have in the next future is: speed.
                >
                > Currently SOAP::Lite is using Expat, which is stable and working.
                > But
                > in the case of SOAP and XML-RPC the payload format is not
                > completely
                > arbitrary but has a rather predictable syntax.
                >
                > I'm sure that a "SOAP-XML" or "XML-RPC-XML" parser can be
                > considerable
                > faster than the generic Expat.
                >
                > Any ideas (a) which parser to use and (b) how to tell SOAP::Lite to
                > use
                > it?
                >
                > \rho
                >
                > ------------------------ Yahoo! Groups Sponsor
                >
                > To unsubscribe from this group, send an email to:
                > soaplite-unsubscribe@yahoogroups.com
                >
                >
                >
                > Your use of Yahoo! Groups is subject to
                > http://docs.yahoo.com/info/terms/
                >
                >


                __________________________________________________
                Do You Yahoo!?
                Get email at your own domain with Yahoo! Mail.
                http://personal.mail.yahoo.com/
              • Robert Barta
                ... How is it done currently? Is it first parsed into some DOM/grove-like structure and then into the Perl data structure? Or is it done in one sweep? In the
                Message 7 of 11 , Apr 6, 2001
                • 0 Attachment
                  Paul Kulchenko wrote:
                  > > Any ideas (a) which parser to use and (b) how to tell SOAP::Lite to
                  > > use it?
                  > Actually you'll be able to specify any parser (SOAP::Lite has
                  > SOAP::Serializer which has SOAP::Parser which refers to XML::Parser).
                  > You may insert your parser in any plca of this chain and in fact next
                  > version will be shipped with regexp-based XML parser that can be used
                  > instead of XML::Parser (it'll be used automatically or you may
                  > specify it explicitly).

                  :-O. I'm certainly looking forward to that.

                  > But the main problem is not in parser's speed. Result of parsing is
                  > represented as Perl data structures and that part affects
                  > performance.

                  How is it done currently? Is it first parsed into some DOM/grove-like
                  structure and then into the Perl data structure? Or is it done in
                  one sweep?

                  In the early days of RPC programming (Sun-RPC) the developer had
                  to specify the interface between server and client in a language
                  independent way (people nowadays would create a WDSL).

                  Then a 'compiler' (rpcgen in that case) would create

                  - a client stub (faking a local subroutine, serializing, sending)
                  - a server stub (server infrastructure, dispatcher)
                  - and all serializing/deserializing routines

                  This means, that, if you had a C structure like

                  struct A {
                  int i;
                  char[30] s;
                  struct B b;
                  }

                  A serializing routine in C-source was created:

                  encode_A {
                  do something trivial with i;
                  do trivial with b;
                  &encode_B (b);
                  }

                  Similar for deserialization.

                  This means, that we could trade of flexibility (interpretation at
                  runtime)
                  with speed. Something I would be happy to do.

                  > I was even thinking about do NOT parse the whole message, just
                  > extract the information about method and parameters and represent
                  > them as tied variable, so as soon as you need it, I'll use XPath or
                  > something like that and will get you value, but I don't think that
                  > it'll be really benefitial. The problem is that if you get request
                  > with parameters a, b, and c that basically means that you'll need all
                  > of them and there is no value in delaying parsing.

                  Well, maybe but sometimes this could be useful. This concept is known as
                  'futures' or 'delayed/lazy evaluation'.

                  As an example of a server-side method:

                  sub do_important_stuff {
                  my ($a, $b) = @_;

                  # do validation of some parameters
                  unless ($a->id) {
                  die "inconsistent data, go away";
                  };

                  # only now the rest matters
                  ..... $b ....

                  }

                  I could even imagine that for SOAP (server-side AND client-side) this
                  could be almost transparent:

                  sub do_important_stuff_lazy {
                  my ($a, $b) = @_; # not real values, only XPath-like expressions
                  to the message

                  unless ( $a->id ) { # this is 'overloaded', resolves XPath, returns
                  value
                  ....
                  }
                  }

                  This works fine for objects where I can do overloading. For arrays,
                  hashes, ...
                  this does not work (as [], ->, {} cannot be overloaded in Perl).

                  \rho
                Your message has been successfully submitted and would be delivered to recipients shortly.