You misunderstood the proposal. Nobody wants to provide an alternative WebSocket API. The proposal is that WebSocket API can be used _together_ with JAX-RS API in the same application, just as I described in my scenarion: Upgrading a JAX-RS HTTP connection to a WebSocket API session.
From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
Sent: Donnerstag, 11. Dezember 2014 17:59
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] Re: Welcome to the JAX-RS 2.1 EG
On 11 Dec 2014, at 17:55, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
On 11/12/14 16:43, Marek Potociar wrote:
On 10 Dec 2014, at 23:54, Markus KARG <markus_at_headcrashing.eu> wrote:
* The list names SSE but not WebSockets. Is this to be understood as
really
SSE only, hence definitively no WebSocket support?
There's another JSR for WS.
What if somebody wants to write a JAX-RS application which shall open a
WebSocket as a reaction to an HTTP method, and which has to forward events
on that WebSocket received by JAX-RS Client API? If we allow SSE, then
people will ask how to do something like that with WebSocket and need a
one-stop blueprint shop. I doubt people would understand that JAX-RS spec
explains how to do such a scenario with SSE, but says nothing about
WebSocket, while WebSocket spec says nothing about JAX-RS in turn. That's
why I'm asking.
To those people, my answer would be that SSE is a special case of media type working on top of HTTP request-response model. There is no further magic behind it and as such it can fit quite neatly into JAX-RS programming model. In WebSocket, there is no HTTP and no request/response relationship, which is why Java EE provides a separate API for WebSocket.
Personally I’m not convinced that we need to bring WebSocket into the picture at all. SSE may look similar to WebSocket at first glance, but it is quite different really. IMO, WebSocket do not belong to JAX-RS spec, neither as a topic and nor as an example.
People do use it though for doing interactive Web UI applications. I don't have the statistics of how widely it is used but it is probably more deployed than SSE, at this moment of time.
It might be reasonable to do some work, may be in the future, to let JAX-RS developers to participate in such activities too,
Opening an ice-box JIRA is a good compromise IMHO :-), no specific targets but can be tracked
Frankly, I do not see us introducing another WebSocket API in Java EE. We would need to present a lot stronger arguments to Java EE platform spec leads rather than “JAX-RS users use WebSocket a lot in their applications”. Let’s focus on areas where we can be realistically successful instead.
Cheers,
Marek
Thanks, Sergey
Cheers,
Marek
If that is true, then it
might at least good to add an example to the specification how to use
WebSockets with JAX-RS and describe why there is no need for explicit
WebSocket support due to that.
I don't know if this belongs in our spec, but maybe a best practice document or something like that. Are you volunteering? ;-)
As long as you tell me how JAX-RS and Java WebSocket API can be used
together I'll provide the code sample and some explanative lines if you
like. I have no clue about the Java WebSockets API as I always thought it
shouldn't be an standalone API but has to be part of JAX-RS... ;-)
* Why is it JSR 370's responsibility to evaluate MVC requirements when there
is a separate MVC JSR? What is expected from the JSR 370 EG which cannot be
done by the MVC EG?
_If_ MVC decides to build on top of JAX-RS (TBD), then we _may_ need to evaluate requirements coming from them.
Understood. So it's their turn initially.
Regards
-Markus
--
Sergey Beryozkin
Talend Community Coders
<http://coders.talend.com/> http://coders.talend.com/
Blog: <http://sberyozkin.blogspot.com/> http://sberyozkin.blogspot.com