hi, > Simone Bordet: > As the WebSocket APIs were moved to incubation and are now slated > for JDK 11, it may be worth considering again whether it's the > case to provide a Flow-based APIs.
I second that. There were two main issues pointed out in this thread: > The first one is how to communicate errors back to the user's > code that publishes messages to WebSocket. Isn't it mostly low level, transport errors about which the application can't do much about, but clean up and close the connection? Arguably a cancellation is adequate, or do you have more specific errors and cases in mind? Alternatively, the JSR-356 WebSocket API provides a single onError callback on the Endpoint type. I haven't come across any limitations around that. > The second issue is how to communicate completion signals from > processing individual messages. James Roper mentioned this already, but the Netty PooledByteBufAllocator demonstrates it's feasible to recycle buffers transparently without the need for a per-message confirmation. I don't think the argument holds that not having per message completion signals forces unnecessary allocations, garbage creation and copying. There were a "dozen of smaller issues" mentioned. However there were no links to earlier discussions, so I'm not sure what those were. The main purpose of Reactive Streams is to connect components from different libraries. The currently proposed WebSocket API cannot be easily integrated into a Reactive Streams pipeline. One would have to build a bridge to Reactive Streams first and I don't think that should be left as a separate exercise, since Flow is in the JDK and it's the reason why it was introduced, to provide a common contract for such scenarios. > Another point that makes me feeling uncertain is the good comment by > Konrad Malawski about the design of Akka Streams versus e.g. Spring's > Flowable, where the former does not implement RS or Flow interfaces, > while the latter does. One minor clarification first. By "Spring's Flowable" I presume you mean the Flux and Mono types from the Reactor project? Reactor does not depend on any Spring projects, and it is a lower level project. It's directly comparable to RxJava, in fact it implements the same ReactiveX patterns, but more explicitly targeting server-side Java applications vs Android. To the point, I don't think the Flow vs RS contracts should a cause for hesitation. HttpClient already uses the Flow contract and that's the obvious choice for WebSocket too. More broadly, the JDK Flow and the RS contracts are identical, and have identical semantics, so adapting from one to the other is trivial. In most cases applications are not consuming these contracts directly, which is also Konrad's point, so practically speaking I don't see much dichotomy there. Regards, Rossen
