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
>