Markus, sorry for the typo in your name..
On 03/02/2017 11:16, Pavel Bucek wrote:
>
> 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
>>>
>>
>