Hi Marek, Andriy, All
FYI I tried to 'justify' the current design by the spec leads by the
requirement to have an implementation specific
SSEBroadcaster introduced without having to introduce an SSEBroadcaster
Context - the latter would make it possible to pass
SSEBroadcaster as a method parameter which might not be ideal.
I agree with the Andriy's observation though that it does look like it
is a current SSEContext/event stream dependent if SSEContext is passed
as a method parameter.
Perhaps a neater way to work with broadcasters can be found :-)
Sergey
On 15/08/16 08:49, Marek Potociar wrote:
> Hi Andriy,
>
> This is a good observation - thank you for spotting this. I’ll give it
> some thought and come up with a fix proposal.
>
> Cheers,
> Marek
>
>> On 14 Aug 2016, at 04:36, Andriy Redko <drreta_at_gmail.com
>> <mailto:drreta_at_gmail.com>> wrote:
>>
>> Early feedback about JAX-RS 2.1 / SSE specification
>> Hey JAX-RS leads,
>>
>> As some of you may already know, the Apache CXF project is one of the
>> early adopters of
>> the JAX-RS 2.1 specification. In particular, we are currently
>> actively working on implementing
>> SSE support, based on drafted JAX-RS 2.1 API. Along the way we
>> stumbled upon some design
>> decisions which may require a bit of clarification or (hopefuly) a
>> second thought. The use case
>> in question is related to SseBroadcaster. Essentially, the idea
>> sounds pretty simple: events
>> into multiple SSE streams could be easily broadcasted. F.e. here is a
>> pseudo-code for typical
>> scenario:
>>
>> SseBroadcaster broadcaster = new SseBroadcasterImlp();
>>
>> broadcaster.register(stream1);
>> broadcaster.register(stream2);
>> ...
>>
>> broadcaster.broadcast(event1);
>> broadcaster.broadcast(event2);
>>
>> In nutshell, current Jersey's SSE implementation does exactly that.
>> However, in JAX-RS 2.1 API
>> draft SseBroadcaster could be created only from SseContext, f.e.:
>>
>> Response stream(@Context SseContext context) {
>> SseBroadcaster broadcaster = context.newBroadcaster();
>> broadcaster.register(context.newOutput());
>> ...
>> }
>>
>> It kind of works but totally defeats the idea of broadcaster as being
>> independent from SseContext or/and
>> streams it serves. Currently, every time new instance of the
>> SseBroadcaster will be created, with no
>> straightforward way to share it across multiple SSE streams. How it
>> could work though may look like that
>> (the implementation details could vary, just trying to present the idea):
>>
>> private SseBroadcaster broadcaster = SseBroadcaster.newBroadcaster();
>>
>> Response stream1(@Context SseContext context) {
>> broadcaster.register(context.newOutput());
>> ...
>> }
>>
>> Response stream2(@Context SseContext context) {
>> broadcaster.register(context.newOutput());
>> ...
>> }
>>
>> In this case, the SseBroadcaster is truly context-independent, and
>> serves it purpose very well. We were trying to
>> come up with some realistic scenarios for SseBroadcaster utilizing
>> the current specification draft but did not really
>> succeeded. Surely, there are a few way to make it work but they do
>> not look good. Does it make sense? Whould you
>> mind guys to give some clarifications/guidance on that?
>>
>> Thank you a lot!
>>
>> Best Regards,
>> Andriy Redko
>