On Fri, Oct 9, 2015 at 8:07 AM, Paul Sandoz <paul.san...@oracle.com> wrote:
> Hi Pavel, Simone, > > One way to make progress is to get the basic shape of the API agreed on > without flow/resource management features. That probably represented the > simplest form. I think we are very close to that. > > Then lets iterate from that form and consider the additional features > (back-pressure and resource management), see how they fit or push/pull the > basic shape in various directions, and importantly see what additional > demands are imposed on the developer. > The backpressure situation for a framing protocol like WebSocket is a different animal entirely vs more traditional streaming protocols like HTTP. Whatever was come up with back in the HttpURLConnection days is irrelevant today. However, what you came up with for HTTP2 in the new HttpClient could be a good candidate (if portable). Techniques like Flow (reactive-streams) simplifies and solves most of these issues in WebSocket. The backpressure should be based on the feedback at the network level, not the API, as there is almost never a 1::1 relationship of API call to network websocket frame result (except for extremely small, non-extension controlled, frames). Extensions and auto-fragmentation (a requirement for most of the WebSocket over HTTP2 proposals) mess with this in a large way. Then there is also the interleaving of DATA vs CONTROL frames that can mess with this backpressure behaviors as well. Punting on backpressure is going to be a big mistake. Every early implementation of WebSocket has suffered from this. There are many rewrites, API breaking rewrites, underway (in many implementations) to solve this. > Also, I expect those features would need to be co-ordinated somewhat with > the HTTP API to ensure a common pattern and possibly reuse of certain types. > WebSocket (currently) is an upgraded connection, once upgraded it is no longer HTTP or follows any HTTP semantics. Attempting to make it follow the HTTP connection behaviors is a mistake. Now, that being said, once the WebSocket over HTTP2 specs settle down, then this *might* be solved with the new HttpClient and its handling of HTTP2 specific streams (but this is a giant *IF* as there's 3 different proposals for how to accomplish this, some using HTTP2 protocol directly, some using tunneled behavior) However, the existing HTTP/1.1 upgraded to WebSocket connection will likely continue to be different behavior then what will come in the future. The API for the WebSocket client should attempt to find a good middle ground where the connection/framing behaviors are not hardcoded to assume HTTP/1.1 or HTTP/2. Even some of the assumptions in WebSocket currently (like no interleaved TEXT vs BINARY messages) might be invalid in this future WebSocket over HTTP2 world (one of the proposed solutions would utilize the built-in mux of HTTP2 to fix this), then what will you do? If you went with a Flow based solution then this nuance becomes irrelevant, as its up to the connection type to determine behavior. > > -- > > Regarding back pressure, i like what Michael/Pavel did with LongConsumer. > > Regarding resource management. This one is tricky. For HTTP Michael had a > clever trick of piggy backing off the back pressure support, but i think > that might be too clever as it is conflating two independent actions. I > have a hunch that to do this effectively we may need some sort of resource > supplier that is registered with the builder. That supplier defines the > resource management strategy and requirements on a listener consuming > resources (that is somewhat annoying because it couples the resource > supplier with the listener). > > Paul. > > I encourage you to implement now. Don't wait for us. Discover what we've been telling you quickly, the sooner the better, then you'll be on-board with what we have been telling you. We are quite confident of that. Don't repeat the mistakes of the past (bad backpressure, send queues in async, ignoring extensions, bad partial support, bad javadoc), don't reinvent the wheel (untested backpressure techniques), use what you have available to yourself (autobahn testsuite, Flow). - Joakim
