On 25/03/14 15:57, Marek Potociar wrote:
>
> On 10 Mar 2014, at 22:06, Sergey Beryozkin <sberyozkin_at_talend.com
> <mailto:sberyozkin_at_talend.com>> wrote:
>
>> On 10/03/14 20:42, Markus KARG wrote:
>>> I think adding support for SSE to JAX-RS would allow to standardize an
>>> API for a common type of application development problem: How to keep
>>> the client updated to server side changes?
>>>
>>> Example: Chat system.
>>>
>>> Common solution in JAX-RS 2.0: Any type of periodic GET (a.k.a polling
>>> et al), like
>>>
>>> @GET public java.util.List<CharComment> getChatComments() {
>>>
>>> return /* …all_chat_comments… */;
>>>
>>> }
>>>
>>> Possible solution with SSE: Get content of thread so far using initial
>>> GET, then wait for more thread postings using SSE (inversion of control
>>> regarding poll-vs-push).
>>>
>>> But clearly, I do not like the way Jersey proposes it. The API looks not
>>> very RESTful, it more looks like "Servlet++".
>>>
>>> Instead, if we decide to support SSE, we should concentrate on REST and
>>> only add that parts of API that still are RESTful and fit nicely into
>>> JAX-RS as it is designed currently.
>>>
>>> My proposal would be that the API should look like this:
>>>
>>> @GET *_at_WebSocket* public *java.util.Stream<*ChatComment*>*
>>> getChatComments() {
>>>
>>> return this.mySourceStream.filter(…).map(…);
>>>
>>> }
>>
>> I think I really like it:
>> - use a dedicated annotation, the enabler, instead of overloading Produces
>> - Typed stream support; I was thinking yesterday more about
>> introdocing a typed StreamOutput variant. Jersey uses
>> EventOutputStream clearly usable in scope of SSE only, something like
>> what Markus suggests, that can be used with and without SSE, with
>> different data types, will do well
>
> In Jersey, the SSE EventOutput
> <https://jersey.java.net/apidocs/2.7/jersey/org/glassfish/jersey/media/sse/EventOutput.html> extends
> ChunkedOutput
> <https://jersey.java.net/apidocs/2.7/jersey/org/glassfish/jersey/server/ChunkedOutput.html><OutboundEvent
> <https://jersey.java.net/apidocs/2.7/jersey/org/glassfish/jersey/media/sse/OutboundEvent.html>>
Right... It's looking fine.
The only concern is the name 'ChunkedOutput' - it is not cool :-). I saw
references to it earlier, I thought it was to do with the HTTP chunked
encoding. IMHO StreamingResponse reads better, but I can drop it...
Other than that I'd only like to propose that something like
ChunkedOutput (StreamingResponse ?) can be used for non-partial complete
responses too as an alternative to StreamingOutput,
Meaning that the user should be able to write start/end tags (in
whatever format); right now, in CXF, I'm supporting it via
getEntityStream(), I thought a bit about having the explicit start/end
support but decided getEntityStream() can be simpler...But it's up for
the discussion, assuming the idea is supported
Sergey
> ...
>
> Marek
>
>>
>> Sergey
>>
>>>
>>> This is aligned with Java EE 8's base platform which is Java SE 8,
>>> providingjava.util.Stream<T>as an endless pipeline of <T>events send by
>>> server. I assume anybody aware of the new Stream API will recognize what
>>> a method with such a signature will do: Provide not only a single
>>> ChatComment, but actually an endless stream. It is just a simple
>>> extension to what a GET does, actually only shifting the time when that
>>> GET ends -- defined by the client application. The @WebSocket annotation
>>> implies @SSEmuch in the same way as @GETimplies @HttpMethod, opening a
>>> way to extend from WebSockets to more SSE technologies (even @COMETor
>>> other legacy solutions). If JAX-RS provides support for SSE, then
>>> WebSockets is a MUST, since it seems to be the most "native" SSE
>>> extension to HTTP GET. My proposal obviously implies that there is some
>>> source stream injected which serves as the origin of the SSE events, and
>>> that the JAX-RS engine is utilizing ManagedExecutorServer (Java EE) or
>>> some unmanaged ExecutorService (Java SE). As an alternative, in Java EE
>>> environments, the source can be attached to CDI events, hence CDI's
>>> event dispatcher drives this chain.
>>>
>>> As you see, my proposal is much less defined around technical
>>> implementation, but much more around developer's readability and
>>> simplicity of the API. Also it is at-most aligned to Java 8. But
>>> certainly, it does not open doors for any fancy thing one could imagine
>>> with SSE channels in mind, but solely is defined to solve one clear
>>> RESTful problem: How to keep the client updated after an initial GET.
>>> And I think, that is the sole SSE item which has to be covered in a
>>> future RESTful API. Everything else, in my understanding, is not
>>> RESTful, hence is not necessarily to be covered by JAX-RS.
>>>
>>> Regards
>>>
>>> Markus
>>>
>>> *From:*Marek Potociar [mailto:marek.potociar_at_oracle.com]
>>> *Sent:* Mittwoch, 5. März 2014 16:39
>>> *To:* jsr339-experts_at_jax-rs-spec.java.net
>>> <mailto:jsr339-experts_at_jax-rs-spec.java.net>
>>> *Subject:* [jsr339-experts] Adding SSE support to JAX-RS 2.1?
>>>
>>> Hello experts,
>>>
>>> As you may know, the first steps towards starting work on Java EE 8 has
>>> been made already. Among the most important ones was the Java EE 8
>>> Community Survey. As the survey results
>>> <https://java.net/downloads/javaee-spec/JavaEE8_Community_Survey_Results.pdf>
>>> indicate,
>>> there is a very strong support in Java EE community for coming with a
>>> standard API for supporting Server-Sent Events in Java EE 8. Clearly,
>>> one way or the other, SSE support will be added in Java EE 8 platform.
>>>
>>> There are multiple options how to achieve this and one of these options
>>> being considered is to extend JAX-RS API to provide better support for
>>> SSE. Before we make a final decision, I'd like to get your feedback on
>>> whether or not you think that extending JAX-RS API with SSE support is a
>>> good idea.
>>>
>>> To get the idea how such JAX-RS API support could look like, please
>>> check Jersey User Guide section that describes how client and server SSE
>>> support is currently implemented in Jersey 2.x:
>>>
>>> https://jersey.java.net/documentation/latest/sse.html#overview
>>>
>>> I am looking forward to your feedback.
>>>
>>> Thank you,
>>>
>>> Marek
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com