Bill,
> That wasn't my understand. My understanding was that the
> AJAX GET would
> block for a certain amount of time waiting for a response.
> Otherwise,
> you're not really reducing the amount of requests.
I personally don't associate AJAX with reducing the amount of requests. It's
more the opposite. As the interactivity of the UI increases, you have more
requests to handle and for scalability reasons, you don't want them to have
them run for too long on the server.
> What I mean is, the StreamedOutput implementation might want to wait
> from input from another place (chat, JMS, whatever), if the timeout
> fails, then send a REQUEST_TIMEOUT as the response.
I don't think that the StreamedOutput is the right place to control this. I
would see that more in the resource method. Anyway, even if you can connect
and start writing the body, you are never sure that the source content (JMS,
etc.) will always be available during the whole writing. You just need to
live with it or cache all the response before starting to write.
> Yeah, you're right that it doesn't solve the polling problem.
> We'd need a specific contract for that. Still, if dynamic
> streamed data needs to be done in a callback object, the
> callback object needs to be able to report errors.
What about throwing IOExceptions in the write() method that would interrupt
the writing of the HTTP response, maybe closing the socket.
Best regards,
Jerome