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

177Re: [soaplite] keep alive

Expand Messages
  • Robert Barta
    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
      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

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

    • Show all 11 messages in this topic