Hi Pavel, thanks, forwarding a response from Andriy, sorry, we are still
trying to sort out what would be the preferred communication approach
for him, he's working on it only on his own time. Thanks
-----------------------------------------------------------------------------------------
Hi Pavel,
Thank you very much for going through the feedback and clarifying the
decisions made. I agree
with you that calling any method starting with "on*" is sowewhat
cumbersome and it actually
brings a bit different by quite related concern. The SSE API is built on
good foundation
(flow.*) but actually lacks the support from core libraries / frameworks
at the moment.
For example, ideally the SseEventSink could be just plugged to RxJava 2
or Akka Stream
publisher (reactive specification implementors) and those "on*" would
disappear from the
picture completely, they are actually the necessary pieces to make the
mechanism work (in
my opinion). The good example is actually SseBroadcaster, it implements
Publisher and
nicely uses Subscription / Subscriber to send SSE events over.
One of the discussions we have had with Sergey was to enrich SSE API
with ability to
create publishers (f.e. sse.newPublisher(...)) but Sergey was really not
sold to
this idea and after thinking about it, I would agree with him. Indeed,
SSE API becomes
a part of much richer ecosystem. With that being said, I think it would
be sufficient
to have SseEventSink just a pure Subscriber. Or it could be split into
two independent
APIs: Subscriber-based and imperative-based. But this is just an
opinion, I understand
the challenges you are facing, it is indeed neccessary to take broader
context into
account.
Thanks again for taking time to respond to the concerns, those are just
some thougths
which may help (or not) to drive certain decisions.
Thank you.
Best Regards,
Andriy Redko
On 16/02/17 15:30, Pavel Bucek wrote:
>
> Hi Andrey,
>
> thanks for your feedback.
>
> Thanks for bringing this up, since I am really struggling with this
> API. Not saying I don't like current proposal, but I don't like to
> force users to call any method starting with "on*".
>
> It is not only about #onComplete() vs #close(). Originally, there was
> a method called #write, which could be implemented as default method
> and only call #onNext(OutboundSseEvent). The problem is that
> #onComplete() must be there because of Subscriber contract, so it won
> and #write was removed.
>
> Having #close might seem redundant, same pattern as with #write and
> #onNext. It provides the option to use SseEventSink in try with
> resources block. Which might not be enough to justify the method.
> Also, we currently have #isClosed.. but that can be renamed to
> #isCompleted..
>
> I believe we will have similar issues in NIO, we will have to deal
> with them sooner or later. Ultimately, it will be done during the
> "purge of flow.*". But if you have anything to add now, please do :)
>
> Best regards,
> Pavel
>
> 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
>>
>>
>