Hi Markus, I'm not suggesting to redefine, I'm suggesting to make the
way SSE is implemented in JAX-RS a little bit less technical as far as
users working with it are concerned ?
Re restricting to a single MT for all the events inside a single
channel, is it a bad thing ? I'm not sure. We can always assume that in
theory it is possible, but lets face it, I doubt anyone can come up with
a practical example where multiple MTs are mixed in. In fact supporting
per-event MT can be added later on at a builder level if such a freedom
of formatting is ever needed...
Cheers, Sergey
On 27/10/15 22:32, Markus KARG wrote:
>
> But Sergey, we only should define an API how SSE can be mapped upon
> JAX-RS. We cannot redefine how SSE works. And it is simply the W3C
> that defined that SSE is initiated by sending that particular MT and
> that each single event can definitively have different entity type.
> What you propose certainly looks more familiar, but would redefine the
> W3C-defined semantics of SSE.
>
> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> *Sent:* Dienstag, 27. Oktober 2015 23:25
> *To:* jsr370-experts_at_jax-rs-spec.java.net
> *Subject:* Re: [jax-rs-spec users] SSE Draft
>
> Hi
>
> I have to admit I'm still uncomfortable about a specialized
> Produces(text/event-stream) in this case. I could not figure why until
> yesterday... Basically this is what the SSE spec requires to accompany
> the data going to the SSE channel - but it is orthogonal to the act of
> converting the data into event specific formats such as JSON or plain
> text.
> When myself and possibly other users see Produces they think this is
> the format of the response data.
> Having an SSE-required MT in a method @Produces does not fit well into
> a JAX-RS state of 'mind'.
>
> Letting people set MT for individual events actually loosens the API -
> i.e, the API makes it very easy to do what is obviously not meant to
> be, mixing different formats in a single channel, 1st event is JSON,
> next is XML. Of course we can say the users needs to know what to do,
> but it is different from having an API which does not explicitly
> allows such nonsense operations...In 2.0 one can also do it, say mess
> up with writing into StreamingOutput - but the user needs to try hard :-)
>
> I'd like to return to discussing this idea:
>
> @POST
> @Produces(MediaType.APPLICATION_JSON)
> public SseEvenOutput startDomain() {
> }
>
> or
>
> @POST
> @Produces(MediaType.APPLICATION_JSON)
> @SSE
> public Response startDomain() {
> }
>
> In either case, setting text/event-stream is the responsibility of the
> runtime, something that will be documented in the spec/API, it is
> implicit, while
> @Produces(MediaType.APPLICATION_JSON) represents the format of the
> every event fragment for a given SSE output channel...
>
> Sergey
>
> On 22/10/15 16:11, Sergey Beryozkin wrote:
>
> Hi Santiago
> On 22/10/15 15:29, Santiago Pericasgeertsen wrote:
>
> Sergey,
>
> This is how I reason about media types associated with
> events. First, sometimes the data associated with an event is
> structured, most notably these days it’s JSON. JAX-RS already
> has a facility for mapping Java objects to representations
> (MBR/MBW) whose selection is based on MTs.
>
> This mechanism is there for entities, but it is only natural
> to see if it can be extended for SSE event data. To do so, you
> need to specify an MT for the event’s data. If we don’t allow
> re-usability of this mechanism, we’d either only support
> string messages or build a completely different mechanism,
> which seems like an overkill.
>
> Sure, +1, indeed reusing MBR/MBW for this is perfect
>
>
> I’m still unsure about interceptors: to me interceptors and
> MBR/MBW’s are inseparable, but at the same time it’s not clear
> what advantages they bring in this case.
>
> I've no strong opinion right now about it. I can imagine some
> confusion about the response interceptors/filters meant for
> processing 'main' HTTP channel responses being also used for
> filtering sse events, though I can also imagine may me some events
> being blocked by filters if needed, not really sure right now :-)
>
> Sergey
>
>
> — Santiago
>
> On Oct 21, 2015, at 4:46 PM, Sergey Beryozkin
> <sberyozkin_at_talend.com <mailto:sberyozkin_at_talend.com>> wrote:
>
> Hi Markus - OK, thanks.
> Still looks like a foreign body, this @Produces...
>
> The question about formatting the event data fragments still
> remains,
> If we are including MBW then surely not because we need a help
> with writing String into output stream.
> Oh, actually.
>
> https://github.com/mpotociar/api/blob/master/jaxrs-api/src/main/java/javax/ws/rs/sse/OutboundSseEvent.java#L108
>
> So ended up doing some home work after all :-)
>
> Sergey
>
>
>
>
>
> On 21/10/15 19:05, Markus KARG wrote:
>
> Sergey,
>
> maybe there is a misunderstanding: The W3C SSE
> specification clearly says that the initiation of a SSE
> channel _is_ by declaring a content type of
> text/event-stream. Hence this is not a marker made up by
> JAX-RS, but it definitivel _is_ correct according to the W3C.
>
> -Markus
>
> *From:*Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> *Sent:*Mittwoch, 21. Oktober 2015 13:26
> *To:*jsr370-experts_at_jax-rs-spec.java.net
> <mailto:jsr370-experts_at_jax-rs-spec.java.net>
> *Subject:*Re: [jax-rs-spec users] SSE Draft
>
> Hi Marek
>
> Few comments/questions,
>
> Re the special MediaType vs the MediaType for individual
> event writes,
>
> How is a Media Type for an event data fragment is specified ?
> And can we assume that the same MediaType is used for all
> the event writes ?
>
> If it is a single Media Type then I'd object to the idea
> of a *special* MT, example, if every event write is a JSON
> payload, why do
>
> @POST
> @Produces(MediaType.SERVER_SENT_EVENTS)
> public SseEvenOutput startDomain() {
> }
>
> This actually appears to be a bit off the JAX-RS style
> because we use MediaType.SERVER_SENT_EVENTS as a marker of
> the method which initiates
> SseEvenOutput but not the *format* of the response event
> data chunks, it overloads the concept of Produces IMHO.
>
> Should we just have
>
> @POST
> @Produces(MediaType.APPLICATION_JSON)
> public SseEvenOutput startDomain() {
> }
>
> Which is more in line with a StreamingOutput like pattern ?
>
> The runtime can mark startDomain() as needed given the
> response type is SseEvenOutput and if Response (or
> AsyncResponse ?) are allowed then
> we can do
>
> @POST
> @Produces(MediaType.APPLICATION_JSON)
> @SSE
> public Response startDomain() {
> }
>
>
> Thoughts ?
>
> Cheers, Sergey
>
>
>
>
>
>
>
>
>
> On 21/10/15 11:42, Marek Potociar wrote:
>
> At the same time, it is the spec lead job to steer the
> EG and the JSR outcome. And since it was me and
> Santiago who submitted the JSR charter, EG does not
> need to find interpretations, EG can simply ask the
> spec leads to provide the explanation. 😉
>
> In case of CDI, our intention was to improve the
> alignment of @Inject and scope support. FWIW, we’re
> still hoping that CDI 2.0 will become more modularized
> so that we do not have to formally deal with the whole
> spec (that becomes more and more bloated by features
> less and less relevant to “context and dependency
> injection” problem), only with it’s core pieces. So
> once, again, our CDI alignment is about aligning the
> JAX-RS injection support with CDI. It is NOT about
> integration with CDI eventing (for SSE support or
> whatever other purpose).
>
> Hope the explanation above is clear enough and does
> not require further interpretation in EG.
>
> As for the SSE support, we want to provide a facility
> that fits well into JAX-RS programming model. And
> since SSE is really just a (special) media type, the
> proposed API is building on top of the existing
> support for entity providers in JAX-RS. So to touch on
> the questions you raised in more detail:
>
> - Yes, we plan to leverage message body readers and
> writers for each single SSE event. We do not plan to
> engage Filters and Interceptors with each event, those
> should only be engaged when the request or response is
> initiated.
>
> - Injectable SseEventOutput is certainly an option to
> consider. At the same time, we do need to find a way
> how to provide access to event builder and
> broadcaster, so rather than injecting three separate
> things, it so far seems to me simpler to just inject
> the context and use it to get access to all of the
> important components. In any case, we can simply look
> into this further to see what can be done to make the
> API simpler.
>
> - To your comment "/I do not see why creating the
> SseOutput from an SseContext should be the
> responsibility of the application programmer./”, my
> response is that SSE stream is a representation of a
> resource in the JAX-RS philosophy. So it is only
> natural that the JAX-RS resources return the new
> instance of SSE stream from a resource method. That’s
> the common JAX-RS programming model.
>
> - To respond to your item #3, other than my CDI
> related comments earlier in this email, SSE is a
> standardized spec with well defined standard APIs. It
> IMO begs for a dedicated API. Otherwise it would not
> make any sense to provide a special support for it. It
> is only good that we can come up with a really small
> API (8 classes) that fits well the JAX-RS programming
> model and is tailored to support this technology. SSE
> is a specific technology that covers important, but
> again specific use cases. Coming up with some clever
> abstractions is not going to provide any real user
> value, I’m afraid.
>
> Cheers,
>
> Marek
>
> On 20 Oct 2015, at 22:53, Markus KARG
> <markus_at_headcrashing.eu
> <mailto:markus_at_headcrashing.eu>> wrote:
>
> Well, according to the JCP bylaws, it is the
> expert group to define the outcome of the JSR. So
> it is up to us to interpret the charter as we
> like. ;-)
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Dienstag, 20. Oktober 2015 22:43
> To:jsr370-experts_at_jax-rs-spec.java.net
> <mailto:jsr370-experts_at_jax-rs-spec.java.net>
> Subject: Re: SSE Draft
>
> Hi Markus
>
> I suspect it is about better support for Inject,
> etc, but not sure
>
> Cheers, Sergey
> On 20/10/15 21:37, Markus KARG wrote:
>
>
> If we cannot, why did the JCP accept the JSR 370
> charter, which clearly requests CDI integration?
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozkin_at_talend.com]
> Sent: Dienstag, 20. Oktober 2015 22:23
> To:jsr370-experts_at_jax-rs-spec.java.net
> <mailto:jsr370-experts_at_jax-rs-spec.java.net>
> Subject: Re: SSE Draft
>
> Can a 2.1 (non major version) introduce a strong
> CDI dep ? MVC is a diff
> story.
>
> Sergey
>
> On 20/10/15 16:26, Bill Burke wrote:
>
>
>
> On 10/19/2015 5:19 PM, Markus KARG wrote:
>
>
> (1) Maybe I missed the code line, but will it be
> possible to send an
> entity so MBWs, Filters and Interceptors are
> getting involved? In the
> end, we do not write an SSE server, but actually
> do add SSE to JAX-RS.
>
> Like:
> sseContext.newEvent().name("custom-message").data(myEntity);
> =>
> use MBW to stream entity, applying all filters and
> interceptors that
> are registered for the resource class that owns
> this SSE channel.
>
> (2) I am not convinced that the complexity is
> needed. Why is there a
> SseEventOutput and an SseContext? Can't we simply
> inject an SseOutput
> in the resource automatically? I do not see why
> creating the
> SseOutput from an SseContext should be the
> responsibility of the
> application programmer.
>
> (3) I am not convinced that the technology of SSE
> should also bring
> with it its own eventing subsystem. Wouldn't it
> make more sense to
> rely on CDI events? Using CDI events we could
> allow events origin
> from other Java EE components (like JCA, MDB or
> timed EJBs) to be
> forwarded in a protocol-transparent way into the
> JAX-RS container,
> which then is the only one that has to know that
> SSE is used to
> transport the event to the http client. As JAX-RS
> is an integral part
> of Java EE, and as SSE is a web-only technology, I
> don't like the
> idea that either non-web-components are polluted
> by SSE, or
> non-web-events couldn't be forwarded to SSE clients.
>
> What would SSE over CDI look like?
>
>