Thanks for the forward,
do you know who was the original addressee? (I don't see this one in my
mailbox..). Why am I asking? I'd like to not lose any feedback :-) So if
there is something I can do to provide better way for anyone to provide
feedback, I'm willing to do that.
Thanks,
Pavel
On 16/02/2017 12:08, Sergey Beryozkin wrote:
> Forwarding on behalf of Andriy
>
> Thanks, Sergey
> On 15/02/17 23:28, Andrey Redko wrote:
>> Hi Pavel,
>>
>> My apologies for hijacking experts group but thanks a lot for the
>> revisiting and updating SSE API part of the JAX-RS specification.
>> Personally, I think it looks much better, modern and aligned with the
>> reactive paradigm which industry is moving towards. One particular
>> concern I would like to bring up is related to SseEventSink API,
>> particularly regarding *close()* method. As SseEventSink is
>> Flow.Subscriber at the same time, there is a conflict between
>> *close()* and *onComplete()* methods. Typically, *Flow.Subscriber*
>> has a following lifecycle:
>>
>> subscriber.onNext(...)
>> subscriber.onNext(...)
>> subscriber.onNext(...)
>> *subscriber.onComplete()* *<---- We are done here*
>>
>> While the current examples do that:
>>
>> subscriber.onNext(...)
>> subscriber.onNext(...)
>> subscriber.onNext(...)
>> *subscriber.close()* *<---- We are done here*
>> *
>> *
>> I think this duality on implementation level could be solved, but on
>> API level it might cause confusion: what should be called,
>> *onComplete()*? *close()*? both? Taking into account the
>> Flow.Publisher <-> Flow.Subscription <-> Flow.Subscriber, there is
>> only *onComplete* method which will be called as part of the
>> processing. Does it make sense to simplify SseEventSink API by
>> removing the close() method as it will be fully replaceable by
>> *onComplete*?
>>
>> Thank you very much.
>>
>> Best Regards,
>> Andriy Redko
>
>