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.