If it's a question of resources for building a separate Flow based API on top of the existing API provided, then perhaps we could help? I could certainly implement it outside the JDK in the coming months, would the HTTP client team be willing to consider folding it in as a utility alongside the WebSocket API in the JDK? I know that's not a zero resource thing, but assuming I can produce something reasonable, reviewing it should be cheaper than implementing it. Also I don't know if there's any work being done on a TCK for this, and whether inclusion of this in the JDK would require a TCK to verify it.
On 20 February 2018 at 08:41, Simone Bordet <simone.bor...@gmail.com> wrote: > James (hi! :) > > On Fri, Feb 16, 2018 at 12:55 AM, James Roper <ja...@lightbend.com> wrote: > > The question for me then is whether there is value in introducing an > > additional higher level API (ie, a reactive streams based API) for the > > purposes of integration with other libraries that provide RS support. > > I have mixed feeling about this. > > I first tried to push the WebSocket APIs to be Flow-based when they > were slated for JDK 9 official inclusion. > 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. > > However, Pavel's point about the limits of the Flow APIs still stand, > so a Flow API may be useful, but less generic. > > 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. > Now that we have the dichotomy of RS and JDK's Flow, it is easy for > Akka Stream implement methods such as asRSPublisher() and > asFlowPublisher() so that they work in both environments (with - yuck > - multi-release jars). > It would be harder for Spring's Flowable to provide support for both > RS and Flow. > > So at the end I would like to see a *separate* Flow API on top of the > current WebSocket API, but who's going to implement it ? > Would be great to standardize a community effort, but even better if > the JDK provided it. > > > Introducing another API, regardless of what that API is, obviously has > > drawbacks as it increases the surface area of the API, and thus > complexity, > > and also potentially introduces confusion for application developers as > they > > now have two different ways of achieving things, and they need to know > which > > to use when. So, the value of that API must be high enough to outweigh > those > > drawbacks. I strongly believe that a Reactive Streams based API does add > > enough value to do that - and the post that I shared in my previous email > > demonstrates how an ecosystem where reactive streams is embraced can > provide > > a lot of value to application developers. So I'm happy to talk more here > > about use cases and code samples etc if you don't agree here. > > I personally don't question the value of a RS or Flow API. > It's just a matter of resources - we can ask Oracle to do it, but if > they don't have resources to do it, then the road ahead is > complicated. > I see better a Flow wrapper of the JDK WebSocket APIs under the > Reactive Extension (https://github.com/Reactive-Extensions) or > Reactive Streams (https://github.com/Reactive-Streams) umbrella. > That would perhaps have less resource issues and still give a unique > library rather than a gazillion similar wrappers. > > > For signalling errors upstream, in all the cases that I've worked with, > > we've never found a reason that sending the error downstream, and just > > cancelling upstream, is a problem. At the end of the day, there is only > one > > thing that can fail, the TCP connection, and if it fails, both upstream > and > > downstream will fail - there is no such thing as a half failure in TCP. > > HttpServlet.service() allows to throw exceptions that the Servlet > container must handle by running the error page algorithm, which is > user code. > A Subscriber (provided by a library) encounters an exception while > performing its job. > Since it comes from a library, the library itself does not know how to > handle the error because it does not know in what environment it is > being used. > The common solution I saw in RS libraries for this is to provide > library specific APIs that registers a callback that is invoked in > case of errors. > Another common solution is to have an inverse RS that relays errors in > the opposite direction. > With this library specific APIs, an app running in a Servlet Container > can trigger the error page algorithm depending on the error provided > by the library. > In this way, the error is reported upstream but using an out-of-band > channel specific to each RS library. > And it is *necessary* to notify the error upstream. > > Now we can argue forever about whether the mechanism should be part of > the RS APIs or not (e.g. Subscription.cancel(Throwable)), but the > decision has been made and it's not there, and can be done with an > out-of-band, library-specific, callback. > I'm not trying to change the RS APIs - I tried already (hello Viktor > :) and been convinced that the minimalist design has advantages and > that the couple of things that may be lacking can be done anyway with > little effort. > > However, the fact that the minimalism of the RS API does not include a > notify-errors-upstream mechanism does not mean that it's not necessary > or not useful. > > I'm pretty sure that writing a WebSocket proxy would require such > notify-errors-upstream mechanism, so a generic RS wrapper around the > JDK WebSocket APIs would need to consider that - might be a callback > or a returned Publisher in the opposite direction. > I may be proven wrong - I have not written it myself and for this kind > of things often the details are hidden until a serious implementation > effort is attempted. > > Thanks ! > > -- > Simone Bordet > --- > 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 > -- *James Roper* *Senior Octonaut* Lightbend <https://www.lightbend.com/> – Build reactive apps! Twitter: @jroper <https://twitter.com/jroper>
