Hi Simone, thanks. I'm currently looking into this.
> On 8 Sep 2015, at 21:18, Simone Bordet <simone.bor...@gmail.com> wrote:
>
> Hi,
>
> On Tue, Sep 8, 2015 at 8:34 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote:
>> Hi Simone, thanks for looking at this!
>>
>>> On 8 Sep 2015, at 17:29, Simone Bordet <simone.bor...@gmail.com> wrote:
>>>
>>> Uh, please no.
>>>
>>> JDK 9 will like ship juc.Flow, so I would recommend to base on that
>>> API rather than reinventing a new API every time to do backpressure.
>>
>> 1. To be honest, I don't think Flow API is a good match here. It's a
>> high-level
>> (very abstract) API.
>
> You are misunderstanding it. It's actually a very low-level API, and
> some even call it a protocol.
>
>> I assume people might later adapt WebSocket API to Flow
>> API, but I still don't think we should implement it in terms of Flow API in
>> the
>> first place. For example, how do you see the
>> Flow.Subscription.request(lonJust rely on APIsg n)
>> would work here exactly? Should n (number of items) be a number of bytes?
>> Frames? Chunks? Messages? Only bytes from the list above gives one control
>> over
>> back-pressure. Messages/Chunks/Frames may vary in size significantly.
>
> Typically, request(long) should match what is being received in
> Subscriber.onNext(T).
> However, I know of people that want to be more fine grained, and may
> receive a ByteBuffer, but backpressure on the number of bytes
> consumed, but this requires some sort of buffering.
> It's an implementation detail; application typically use higher level
> APIs with a richer interface.
>
>> What would an app do if it asks for one more message, but the message would
>> turn
>> out to be a 100M file?
>
> If you ask for 1 message and you receive a 100M buffer, it is either
> already in memory of the publisher, or it is mapped to native memory.
> Either case, you can handle it just fine; when you are done with it,
> you can request one more of those buffers.
>
>> 2. I wouldn't base the WebSocket client on an API that is not a part of JDK
>> yet.
>
> Flow is scheduled to be part of JDK 9, AFAIK. If it's not anymore,
> then I would suggest at what Flow (or reactive streams) provides and
> do something similar.
> For your interest, we are talking about using Flow for the Servlet
> APIs and the new HttpClient.
>
> In any case, the basic use cases should work out of the box. With the
> current APIs, you cannot even write an echo service that is fully
> async.
>
>> A question if I may. Are there any examples of inherent issues in the model
>> of
>> communicating back-pressure proposed for the WebSocket API that are absent in
>> Flow's approach?
>
> There are no examples of how one is supposed to use the API you are
> proposing. If I missed them, please be gentle and relink them to me.
>
> The solution you proposed with BackpressureHandler is racy and forces
> applications to do horrible synchronizations, or the implementation to
> impose a thread model, which is also a bad thing.
> I understand it's a proposal, but don't go that way. There exist
> proven solution already, just reuse them.
>
> Please, write a proxy example and show to all of us how the current
> proposed API would work.
> It must be fully async: you cannot read until you finished write and
> viceversa.
>
>>> I don't see how this would work in general.
>>> Because you mentioned it,
>>> An application that acts as a proxy may have chunk1 available, know
>>> that is not the last, but not have chunk2 available yet. And it cannot
>>> buffer them.
>>
>> It just sends out the chunk1 to the next peer in the chain. How's that
>> different
>> from handling WebSocket frames on an intermediary? Think of chunks as frames
>> if
>> that helps.
>
> Please, write the simple proxy I talk about.
> You will realize that you cannot do what you think you can.
>
>>> An application cannot implement this with an Iterator.
>>> Again, the problem is already solved by juc.Flow.
>>
>> Again, what problem?
>
> The async problem. The current API will force a thread to block.
>
>> BTW, due to some previous criticism of Outgoing it will likely be removed.
>
> Okay.
>
>> I think we would use suspend/resume. The "proxy case" as far as I understand
>> is
>> no different from any other case where back-pressure control is needed.
>
> Write the proxy case with the current API and post it somewhere for reference.
> I could not write it, but perhaps I have misunderstood the API proposal.
>
> I hope that in the spirit of other APIs, this API could be
> re-implemented using service providers (j.u.ServiceLoader).
> As such you cannot expect to create Oracle-private subclasses of
> Outgoing (or whatever solution replaces it) and have an alternative
> implementation cast them down to figure out how to extract the data
> they contains.
>
> Thanks !
>
> --
> 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
