On Tue, Mar 2, 2010 at 09:49, Jeff Brown <jeff.br...@gmail.com> wrote: > The feature is pretty simple in its essence, it just means that a method > call can produce multiple responses. In a non-blocking implementation with > asynchorous callbacks, this would just translate into a callback being > called multiple times. > > There could even be two callbacks provided to the RPC stack, one to receive > the response (called exactly once as now), and one to receive additional > streaming messages. However it would be just as easy to use a single > callback and to have the client examine the message type to determine > whether the message is a final reply or a streamed intermediate response.
The ownership of the thread in which the callback executes has to be determined, this also means there is a lot of error conditions to take care of. Why not provide a streaming transport which would allow a continuous flow of req/resp or even one req several resp? This could probably be easily done and would not imply modifying the IDL or the generated code. Mathias.
