in reply to streaming SOAP::Lite service ?

To the best of my knowledge, streaming is not possible with SOAP::Lite.

Because you return your completed data structure to SOAP::Lite, it doesn't begin processing the result until that point. For some types of deserialization (eg, RPC-encoded arrays), it needs the entire data structure to before it can begin emitting the XML string

If you were to use an NPH CGI script (because if it's parsed by the webserver, it's going to wait 'till it knows the file size so it can insert it in the HTTP header), and document/literal encoding, you could probably emit the XML as the string is being serialized.

It's been a while since I've done serious digging through SOAP::Lite's serializer, so I don't know how easy it would be to piggyback on their serializer (so that you don't have to deal with the headache of supporting multiple versions of XML Schema on your own)... this might be something that you could do, and provide as an alternate SOAP toolkit, or try to coordinate into Byrne's plans for SOAP::Easy.

Replies are listed 'Best First'.
Re^2: streaming SOAP::Lite service ?
by erroneousBollock (Curate) on Mar 28, 2007 at 02:23 UTC
    The more digging I do, the more I agree - SOAP::Lite doesn't have streaming in mind :-(

    At this point it seems that (without too much trouble) I should be able to get a SOAP::Lite subclass to serialise a 'stub' document, and a SOAP::Transport subclass to send only part of the stub to the client; I can do the same for the closing tags from the stub.

    I could probably treat each 'yield' of the continuation like a 'return' from the dispatched method -- proceed to serialise as normal -- but then somehow pull out the 'payload' of the serialised document as a fragment.

    I guess the hard parts will be discovering how to:
    • create a re-entrant generic SOAP::Transport subclass, which will work such that it can be injected into the inheritance chain of the existing SOAP::Transport subclasses.
    • do 'continuations' in a natural way in dispatched methods.

    If possible, I'd like to keep the usage of 'streaming' as transparent possible, so that the user of my toolkit can easily select whether to stream results -- either at compile time, or at runtime (perhaps based on some preliminary calculation of result-set size).

    While I am concentrating on SOAP for the moment, I'll also want to look at doing all this for JSONRPC... but seeing that it's modelled after XML::RPC which is similar in structure to SOAP::Lite, I guess that shouldn't be too much of a problem.

    -David.
[reply]

In Section Seekers of Perl Wisdom