Hi Pavel
There was an issue I was trying to raise when the SSE draft was
originally proposed.
Specifically, it was about a default media type for SSE data.
Right now one needs to set a media type with the SSE builder. The
question was if we could let people use @Produces,
so that they do not set it every time an SSE data is returned, similarly
to the way it is done in the 'traditional' JAX-RS - one either
uses @Produces or uses Response to customize
What do you think ?
Thanks, Sergey
On 03/02/17 17:56, Pavel Bucek wrote:
>
> perfect, thanks! :-)
>
>
> On 03/02/2017 18:50, Markus KARG wrote:
>>
>> https://java.net/jira/browse/JAX_RS_SPEC-544 :-)
>>
>> -Markus
>>
>> *From:*Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
>> *Sent:* Freitag, 3. Februar 2017 11:16
>> *To:* jsr370-experts_at_jax-rs-spec.java.net
>> *Subject:* Re: High Level API for SSE support
>>
>> Hi Marcus, Sergey,
>>
>> thanks for thinking about this topic and coming with an enhancement
>> (or maybe extension is a better name).
>>
>> I believe the idea is a sound one. I also share Sergeys opinion that
>> JAX-RS should provide SSE support on the level which is currently
>> proposed.
>>
>> I know you won't like this, but.. can you please formalize your
>> proposal as a jira ticket?
>>
>> We need to keep "closing" stuff instead of adding and I we don't even
>> have any comprehensive review of the proposed SSE yet. If we'd
>> include this as part of it, it would most likely significantly
>> prolong the review period, not mentioning that it can be treated as
>> completely separate feature. We can call it "High level SSE API".
>> Also, the idea will need some work - currently, there is no mention
>> of the message format (I believe it will need to be pluggable, we
>> don't want to define any "standard" there), relation to the existing
>> API (esp. broadcaster), etc.
>>
>> Having said that, please don't take it as "I don't want to hear your
>> thoughts" - it's exactly the opposite. But I believe there is a
>> general conclusion: "we want to have API similar to what has been
>> proposed by JAX-RS Spec leads". Let's finish that one. We can build
>> on top of it later.
>>
>> Thanks and regards,
>> Pavel
>>
>> On 03/02/2017 10:41, Sergey Beryozkin wrote:
>>
>> I think the proposed SSE API should stay (to let users control
>> SSE flows in a fine grained manner when needed),
>>
>> However offering the users an option to cover the basic SSE flows
>> with the use of annotations is interesting which
>> if accepted should be complementary IMHO
>>
>> Cheers, Sergey
>>
>> On 02/02/17 23:22, Markus KARG wrote:
>>
>> Experts,
>>
>> Oracle's current SSE API proposal clearly is a good API for
>> SSE. The question is, whether it really fulfils what
>> application developers expert from JAX-RS in particular.
>>
>> There might be programmers that don't like to explicitly
>> learn a new (and rather complex) set of classes and methods
>> just to get the additional benefit of update notifications,
>> and that the style of the SSE API does not very well fit into
>> the style of JAX-RS. SSE API is completely algorithmic, while
>> server-side JAX-RS is mostly declarative. I could imagine
>> that some programmers would love to get a high-level SSE
>> support in JAX-RS that more looks like "SSE inside JAX-RS"
>> and less like a standalone SSE API.
>>
>> To illustrate, let me give an example. Think of a simple CRUD
>> application that works pretty well in JAX-RS 2.0 already
>> (@POST / @GET / @PUT / @DELETE). Now the developers decide
>> that once data is updated (PUT) or deleted (DELETE), the
>> client shall be notified about that immediately using SSE
>> technology with minimal additional code. But the amount of
>> additional code lines with the new SSE API is really heavy
>> and clutters the previously clean application with lots of
>> SSE special code.
>>
>> So I wonder whether it might be beneficial to provide some
>> high-level API that simplifies this use case?
>>
>> For example, it could look like this (simplified for
>> illustration purposes):
>>
>> @SSE public class MyResource {
>>
>> @GET @SseInit public void notifications() {};
>>
>> @POST public void create() {…};
>>
>> @GET @Path("{id}") public MyObject read() {…};
>>
>> @PUT @SseNotify public void update() {…};
>>
>> @DELETE @SseNotify public void delete() {…};
>>
>> }
>>
>> The idea would be the SSE API as outlined by Oracle is used
>> under the hood by the JAX-RS container. Once a requests to
>> get SSE notifications by calling the @SseInit-annotated
>> GETter, the JAX-RS container sets up an implied SSE
>> subscription for that client with this resource. Whenever the
>> JAX-RS container leaves the body of @SseNotify-annotated
>> methods, it pushes notifications to that subscriptions (the
>> messages as synthetically built from the HTTP method and the
>> URL, so the client knows what the message means).
>>
>> This is not as far as flexible as Oracle's full-blown SSE
>> API, but it is only intended as sugar ontop for simple but
>> frequent use cases.
>>
>> -Markus
>>
>