Or per-event MT approach can still work where, if set, it overrides a
method specific Produces, exactly as it works with a regular JAX-RS
response.
So I guess the only thing I suggest is to make setting text/event-stream
implicit and keep Produces for specifying the event format if preferred...
Sergey
On 27/10/15 23:22, Sergey Beryozkin wrote:
> 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>mailto:sberyozkin_at_talend.com]
>> *Sent:*Mittwoch, 21. Oktober 2015 13:26
>> *To:*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> 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
>> 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
>> 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?
>>
>>
>