Hmm, let me see how the server implementation changes fare. I have a feeling it'll be pretty straightforward. Handling multiple responses really shouldn't be any more difficult than just handling one response.
Worst case, this is all stuff that can be done by framework users by using the protocol handlers directly. Jeff. On Tue, Mar 2, 2010 at 12:57 AM, Mathias Herberts < mathias.herbe...@gmail.com> wrote: > 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. >
