jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: JAX-RS 2.0 API for asynchronous server-side request processing

From: Marek Potociar <marek.potociar_at_oracle.com>
Date: Wed, 27 Jul 2011 21:44:16 +0200

On 07/25/2011 05:02 PM, Santiago Pericas-Geertsen wrote:
>
> On Jul 25, 2011, at 9:55 AM, Bill Burke wrote:
>
>>
>>
>> On 7/25/11 9:53 AM, Santiago Pericas-Geertsen wrote:
>>>
>>> On Jul 25, 2011, at 8:31 AM, Bill Burke wrote:
>>>
>>>> In Resteasy, we do something much simpler than Atmosphere and the app-developer decide how they want to handle responses. Atmosphere seems a little ambitious to add to the spec as it looks like a full messaging solution, but I'm willing to support the addition as it looks kinda cool.
>>>
>>> We need to decide if want to support "collaborative" applications (like chat) in which messages can be broadcasted to multiple (suspended) connections. On the one hand, these apps are getting ever more popular (with new HTML5 protocols like Server Sent Events and Websockets) and it would be nice to support them; on the other, sending multiple, short messages over the same connection (HTTP streaming) raises some questions in relation to filters, MBR/MBW and the JAX-RS pipeline.
>>>
>>
>> Comet style messages ain't really REST, and we would have to implement an on-the-wire protocol, no?
>
> Just to clear, we could also support a broadcast operation without supporting comet-style messages. Essentially, by resuming the connection after the first message is sent. This would give us support for collaboration without all the other issues. JAX-RS implementations could support the non-resuming case as an extension.

I would not want us to add support for other OTW protocols or to support Comet. I simply look for a feature of resuming
multiple requests at the same time. Of course, the basic scenario - similar to the one Resteasy supports today should
not suffer in simplicity because of the extra feature.

Marek