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

sktop is alive and well for internal users at businesses. And the quality of most of that software is so incredibly dismal one wonders how any of it gets sold. JavaFX and WebSockets can put the FIX on that stuff besides being cross-platform with update repositories! Long live desktop application

Re: websockets

tations of WebSockets are designed to be connected to from browsers, non browser clients are still a relatively niche use case for WebSockets. And so servers are going to look to the browser for what features that should give priority to. If a browser doesn't support X, then it's

Re: websockets

no formal definition of high/low level, but in the case of WebSockets, we can draw some lines based roughly on what web browsers (which is the target application developer experience that >WebSockets were designed for) support as being high level, and what the WebSocket protocol allows beyond

Re: websockets

f this API. Yes, there's no formal definition of high/low level, but in the case of WebSockets, we can draw some lines based roughly on what web browsers (which is the target application developer experience that WebSockets were designed for) support as being high level, and what the WebSocket

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

ed exactly for that purpose - 1009. I don't think a high level API should seek to make every feature of WebSockets available just because it's possible in the protocol - I think that would be over-engineering, over complicating things for application developers. I think a high level API sh

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 (websocke

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

o registered listeners. And if the > programmer wants to process intermediate results that would not be too > difficult for the listener to track. > > I can understand the potential need for "back-pressure" but I think > conserving the asynchronous nature of WebSocket is a h

Re: websockets

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 th

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 thi

Re: websockets

ocket is a high priority as well. Indeed, I've built my application on that feature of WebSockets. Thanks again. At least I'm a bit more enlightened about the issue being addressed. Chuck On Fri, Feb 9, 2018 at 11:38 PM, James Roper wrote: > Hi Chuck, > > Presumably this

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 prop

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 con