On 25 Mar 2014, at 17:50, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> 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...
I do not have a problem with renaming suggestion at all.
>
> 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,
That's what we actually use it for - it is a generic type for identifying entities that are sent in partial chunks/pieces (not HTTP chunked).
> 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
We can certainly improve upon the current version in Jersey.
Marek
>
> 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