websockets

[Konrad Malawski]

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 (rstoyanchev at 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

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180222/cd63d6d0/attachment-0001.html>