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. 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(long 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. What would an app do if it asks for one more message, but the message would turn out to be a 100M file? 2. I wouldn't base the WebSocket client on an API that is not a part of JDK yet. 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? > 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. 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. > An application cannot implement this with an Iterator. > Again, the problem is already solved by juc.Flow. Again, what problem? > I don't understand why Outgoing has no instance methods ? What instance methods would you like to see there? > How is the implementation supposed to interact with it, Have a look at [1] lines 702, 713, 724 and 735. The implementation will simply cast Outgoing to an appropriate subclass later. BTW, due to some previous criticism of Outgoing it will likely be removed. > and an > application write a WebSocket message if it cannot use the predefined > static methods ? Sorry, I didn't understand the question. >>> - 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. 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. > Again, look at how it is done in juc.Flow. Could you please be more specific here? Are you talking about examples in java.util.concurrent.SubmissionPublisher? If yes then why you think this is more suitable for us? Thanks. -Pavel
