Re: websockets

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 w

Re: websockets

Well, yes, WebSocket on the server is an entirely different beast (at this time -- although perhaps jdk9 WebSocket will make it's way to JEE someday) -- and that definitely has to work with browsers. But the whole world is not going to browsers as much as some would have us believe. The desktop i

Re: websockets

Hi Chuck, I'm definitely not saying that the Java client is for browsers. I'm saying that the WebSocket protocol was designed to be used by the API provided by web browsers. No protocol is ever implemented on an island, it is implemented with an intended use case. To best understand a protocol, to

Re: websockets

James, this does not make any sense to me. Last I heard browsers no longer run java. Why would JSE give a hang about designing a communications mechanism for browsers on the client side? That is the job of the browser developers. On the other hand, JSE WebSocket is the best thing to come along

Re: websockets

Hi Simone, Sorry, I think there's been some missed information here. I am in no way suggesting that the API as provided currently should be changed or replaced. What I'm suggesting is that a high level adapter be provided out of the box that provides Reactive Streams support on top of this API. Ye

Re: websockets

James, On Mon, Feb 26, 2018 at 4:37 AM, James Roper wrote: > On the topic of error handling. A high level API doesn't need to report each > individual error with sending. Depends on what you mean by "high level APIs"... I guess there is no formal definition of that, as one can even think that th

Re: websockets

On the topic of error handling. A high level API doesn't need to report each individual error with sending. So firstly, it is impossible to report *all* errors with sending, since it's impossible to know, once you send a message across the network, whether it got there or not. So if an application

Re: websockets

Rossen, > On 23 Feb 2018, at 21:15, Rossen Stoyanchev wrote: > > hi Pavel, > > On Thu, Feb 22, 2018 at 8:43 AM, Pavel Rappo > wrote: > > 1. If there is no error reporting, then how would the user know if there's > something wrong with the data they send? I'm tal

Re: websockets

hi Pavel, On Thu, Feb 22, 2018 at 8:43 AM, Pavel Rappo wrote: > > 1. If there is no error reporting, then how would the user know if there's > something wrong with the data they send? I'm talking about > incomplete/malformed > UTF-8, fragments intermixing, sending messages after a Close message

Re: websockets

Hello Rossen, > On 22 Feb 2018, at 02:51, Rossen Stoyanchev 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. T

Re: websockets

​​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 communi

Re: websockets

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 Web

Re: websockets

James (hi! :) On Fri, Feb 16, 2018 at 12:55 AM, James Roper 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

Re: websockets

Hi Pavel, Sorry for taking a while to respond, I've been travelling and wanted to take the time to properly understand the concerns you've raised. The reasoning you've stated for the current API design is all sound, and obviously the choice to go with that design and not others depends on the goa

Re: websockets

Thanks, Pavel, for the additional information. Text payloads will be easily handled. ByteBuffers not so much apparently. Major issues I see now: they can't grow and all the methods I'd want to use are abstract, optional or both. So each implementation I run on will have to be tested to see if

Re: websockets

> On 12 Feb 2018, at 19:29, Chuck Davis wrote: > > > > There is never a way to tell how much data may be > returned. > Reactive Streams speak in terms of numbers of invocations to the onNext method. Not the amount of data. (Please disregard if that's not what you meant.) > > > I am under

Re: websockets

On 12 February 2018 at 18:56, Chris Hegarty wrote: > James, > > On 10/02/18 07:38, James Roper wrote: > >> ... >> >> https://developer.lightbend.com/blog/2018-02-06-reactive-str >> eams-ee4j/index.html >> > > Regarding: https://github.com/jroper/reactive-streams-servlet/blob/7a2a > 651b706bb0612f

Re: websockets

Hi Pavel: Thanks for your input. You guys are a lot smarter than I am so I won't pretend to have a situation you haven't thought about. My typical use case is to fetch database data from the server using ejb. I return the data in serialized java objects to my JavaFX clients (websockets are not

Re: websockets

James, On 10/02/18 07:38, James Roper wrote: ... https://developer.lightbend.com/blog/2018-02-06-reactive-streams-ee4j/index.html Regarding: https://github.com/jroper/reactive-streams-servlet/blob/7a2a651b706bb0612f6d11311e442f82ce307ed2/reactive-streams-servlet/src/main/java/org/reactivestr

Re: websockets

Hello James, Thanks for the comprehensive reply to Chuck's email. Now regarding your own email. > On 10 Feb 2018, at 07:38, James Roper wrote: > > > > But that brings me to a problem that I'd like to give as feedback to the > implementers - this API is not Reactive Streams, and so therefore

Re: websockets

Hi Chuck, (Disclosure: I'm an RS SIG founding member.) On Sat, Feb 10, 2018 at 7:14 PM, Chuck Davis wrote: > Hi James: > > Thanks for your response and the information in your (and other) > blog(s). I haven't had time to learn all the new features of jdk9 yet > so a look at Flow was interestin

Re: websockets

Hi Pavel, I was wondering if you could address the concerns I raised about it not actually using Reactive Streams. It would be great if, having created a WebSocket, a user could just plumb it to another reactive streams source/sink without writing any glue code, but with this, they're going to hav

Re: websockets

> On 9 Feb 2018, at 18:16, Chuck Davis wrote: > > I've been using jdk8 websockets to develop my desktop java > applications. Now that jdk9 is on my machine I started looking at > websockets and I'm not at all sure I like what I see. Can someone > familiar with this feature please explain the r

Re: websockets

Hi James: Thanks for your response and the information in your (and other) blog(s). I haven't had time to learn all the new features of jdk9 yet so a look at Flow was interesting. My first impression is that a time constraint would be better than destroying asynchrony. Rather than telling the s

Re: websockets

Hi Chuck, Presumably this API is similar in intention to the request method used in reactive streams (aka java.util.concurrent.Flow), that is, request is the means by which backpressure is propagated. One major problem with JDK8 WebSockets is there's no way to asynchronously propagate backpressure

Re: websockets

I've been using jdk8 websockets to develop my desktop java applications. Now that jdk9 is on my machine I started looking at websockets and I'm not at all sure I like what I see. Can someone familiar with this feature please explain the rationale for what is happening? I'm concerned, at this ini