Hello everyone, seems I was called out by name so wanted to confirm that point is being understood correctly. (tracking this thread with much anticipation, but don’t want to add more noise, discussion seems pretty healthy so far!).
Rossen clarifies my point very well, but to confirm it myself as well since I was quoted by name on it: The argument about not extending RS/Flowable interfaces directly matters more for libraries that are outside of the JDK (before j.u.c.Flow existed), such as Akka Streams or Reactor, since they were adopting the interfaces early and showing that those things do work, and that there is a will and ecosystem ready to adopt them. In the JDK of course the decision is simple — one simply shall use the types available in the JDK: java.util.concurrent.Flowable, and ignore that the org.reactivestreams.* types exist at all. The contract is the same indeed, so the RS ecosystem now has to work well with both for a while, but anything that is being built anew (esp in the JDK), can assume Flow is the right thing to use. I hope we’d be able to figure out a way to make a Flow-compatible API available, in order to grow the number of connectable APIs by this interface, same as it would be lovely to have File access types implement them as well. I’m a bit lost what the current main question to answer (or prototype) here is, that would be nice to focus on, to decide the viability of such API? -- Cheers, Konrad 'ktoso <http://kto.so>' Malawski Akka <http://akka.io/> @ Lightbend <http://lightbend.com/> On February 22, 2018 at 9:04:22, Rossen Stoyanchev (rstoyanc...@pivotal.io) wrote: 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
