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

Re: [soaplite] keep alive

Expand Messages
  • 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 1 of 11 , Apr 4, 2001
      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 2 of 11 , Apr 6, 2001
        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.