Hi,
On Tue, Sep 1, 2015 at 10:45 PM, Pavel Rappo <pavel.ra...@oracle.com> wrote:
> That's a very good question. The only way sending could be "back pressured" in
> the current API is by blocking completion of the returned
> CompletableFuture<Void>. But given the intention to provide a fully
> asynchronous
> non-blocking API, that's not a right thing to do. I have to think about a
> callback a user can install to be notified when they should put sending on
> hold:
>
> public interface BackpressureHandler {
>
> /**
> * Called by {@link WebSocket} no notify a client sending more data is
> * currently undesirable.
> */
> void suspendSending();
>
> /**
> * Called by {@link WebSocket} no notify a client sending may be resumed.
> */
> void resumeSending();
> }
Uh, please no.
We have already (partially) discussed this argument for the new
HttpClient APIs, and there is no need to reinvent the wheel every
time.
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.
>> WebSocket.Outgoing
>>
>> - What does binary(Iterable<? extends java.nio.ByteBuffer> chunks)
>> and text(Iterable<? extends CharSequence> chunks) do?
>
> They provide a way for an API user to construct a WebSocket message (m) from a
> sequence (c[i], i: 0..n) of consecutive chunks, such that
>
> m = c[0] + c[1] + c[2] + ... c[n-1] + c[n]
>
> where "+" is concatenation operation. It's basically designed for cases when:
>
> 1. the overall size of the message is not known beforehand
> 2. the overall size of the message is too big to fit in a single
> ByteBuffer/CharSequence, or memory is a particularly scarce resource
> 3. it's more convenient for the user to provide something as a sequence of its
> parts rather than as a whole thing
>
> Think of it as some sort of data supplier. This thing also allows not to bring
> "fragmentation" concept in the API.
I don't see how this would work in general.
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.
An application cannot implement this with an Iterator.
Again, the problem is already solved by juc.Flow.
I don't understand why Outgoing has no instance methods ?
How is the implementation supposed to interact with it, and an
application write a WebSocket message if it cannot use the predefined
static methods ?
>> - Why is there no WebSocket.Outgoing chunking equivalent?
>> This will be important for those wanting to deal with streaming behaviors
>> over websocket.
>
> See the answer on the purpose of Outgoing above.
Nope, it's not covered.
Also, you need to address proper backpressure in the websocket proxy
case: read from downstream websocket and write to upstream websocket.
You cannot read more until the write has completed. This is currently
not doable with the API.
Again, look at how it is done in juc.Flow.
Where is TLS support ? Let's not make the same mistake already done in
javax.websocket :)
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
