>> * 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.
>> 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 practices
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