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

Re: [jax-rs-spec users] Proposed Plan

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Fri, 9 Oct 2015 10:01:42 +0100

The animal in the picture in that post is bigger on the right side - I
guess that is why we will have to implement SSE :-)

On 09/10/15 09:43, Sergey Beryozkin wrote:
> I've found this post being very informative:
>
> http://streamdata.io/blog/push-sse-vs-websockets/
>
> Sergey
> On 09/10/15 01:59, Bill Burke wrote:
>>
>>
>> On 10/8/2015 9:37 AM, Santiago Pericasgeertsen wrote:
>>> Hi Julian,
>>>
>>>>>>> (3) SSE
>>>>>>
>>>>>> Are we sure this standard is being used? Its been more than a
>>>>>> year (two?) since we've argued over it. Anybody know what is
>>>>>> winning the "push" protocol wars?
>>>>>
>>>>> I’m not sure what “war” you are referring to. SSE is the only
>>>>> standard for this. Of course, there are other techniques like long
>>>>> polling, etc. but those are just clever hacks more than anything
>>>>> else.
>>>>> ...
>>>>
>>>> HTTP/2 server push
>>>> (<http://greenbytes.de/tech/webdav/rfc7540.html#PushResources>).
>>>
>>> This is much lower level support than SSE and I’m not aware of any
>>> browser API for it like there is for SSE. I think of this as being
>>> infrastructure-level rather than application-level. Maybe SSE can be
>>> routed this way when HTTP/2 becomes ubiquitous, but we are talking
>>> about an API here that would work regardless of how the bits are
>>> transported.
>>>
>>>> And even Websockets…
>>>
>>> WS is not just push, although you can use it that way. We already
>>> have an API in EE for that; however, it’s completely unrelated to
>>> JAX-RS because it is not request-response and it is bidirectional
>>> and, other than the handshake, not related to HTTP. If you just need
>>> push, it is a lot simpler to use a JAX-RS extension for SSE (like
>>> Jersey’s), and you can co-locate your logic with other resources.
>>>
>>
>> What I'm getting at with WebSockets and whatever HTTP/2 has that
>> Julian mentioned, is SSE actually being used? Java EE has a habit of
>> introducing stuff like this that ends up not being used and becomes a
>> maintenance burden for us vendors.
>>
>>
>