On 12/02/13 22:29, Bill Burke wrote:
> I know Marek is gonna have a fit....but...funny things start to happen,
> at least on my end, when you start writing about these things and have
> to explain why this feature is useful...
>
> So.....
>
> Should we remove server-side async http support? What are the use cases
> for it?
>
> 1. Long polling is perhaps the biggest one. The problem is, WebSockets
> and to a lesser extent Server-Sent-Events [1] have pretty much become
> *THE* way of setting up an event channel. HTTP Long polling is legacy.
> Believe me, I've tried to drum up interest in REST-based messaging, but
> WebSockets, et. al. pretty much has took over.
>
> 2. Setting up priority-based request processing. i.e. putting
> CPU-intensive requests into a low-priority work queue.
>
> 3. Implementing fire-and-forget. Immediately sending 202, Accepted to
> the client and re-using the servlet request thread to execute business
> logic.
>
>
> With #1 being legacy, and #3 being a questionable practice, does #2
> really justify having this complicated feature within JAX-RS 2.0? maybe
> there's some additional use cases I"m not seeing? Maybe the callbacks
> add some additional value?
>
>
I would say 'no'. From the user's point of view it just works. Server
side events is still a draft, and both Web Sockets and I'm presuming SSE
streams are difficult to introspect. This feature allows users to write
easy enough OO code and achieve 2. but also the coordination between
different consumers...
Thanks, Sergey