WebSocket client API

[Simone Bordet]

Hi,

On Wed, Oct 21, 2015 at 12:52 PM, Pavel Rappo <pavel.rappo at oracle.com> wrote:
>>> But I'm against of merging flowController with WebSocket.
>>
>> Yet, you did not bring any technical reasons for the split, and
>> "separation of concerns" is just not enough because it can mean
>> anything (and it may even be wrong).
>
> I see what you mean, but my passage above does not contradict this. What I
> wanted to say (but it seems like I've failed the attempt) is that Listener is
> pretty much Flow.Subscription.

I don't see where you can think that Listener is anywhere near
Flow.Subscription at all.
Different set of methods, different purposes, different abstractions.

I really hope you meant that Listener is like Flow.Subscriber.

And you still have not brought any technical reason for that decision.

Speaking of analogies, it's pretty common to implement Publisher *and*
Subscription in the same class when you can only have one listener,
which is exactly the WebSocket case.
Now, Publisher is the "write" part of ReactiveStreams, and
Subscription is the flow control *and* cancelling part.
If you put back the flow control method into WebSocket, you get
exactly that: the write part along with the flow control and
cancelling part.

In ReactiveStream Publisher and Subscription are divided to support
multiple Subscribers.
In WebSocket there is no need to, hence, no need to split them.

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz