Dear Experts,
I understand the concern about standardizing technologies that are not used, and we can come back to that discussion when we evaluate SSE and look at what it takes to support it in JAX-RS. I will try to collect some more evidence about its real-world use in preparation for that.
Having said that, I’d like to return to the discussion of the plan. It seems that there is general agreement that we need to start showing progress to the JCP and the community and that the more focused plan that was proposed can get us there.
I’d like to share a proposal for reactive and non-blocking that we drafted internally. I shall do that either today or Monday at the latest.
Thanks.
— Santiago
> On Oct 9, 2015, at 5:01 AM, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
>
> 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.
>>>
>>>
>>
>