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 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 applications and long live the servers that power them!! 🤓 Oh, yeah, and long live WebSockets!!
On Sun, Mar 4, 2018 at 4:24 PM, James Roper <ja...@lightbend.com> wrote: > 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 > understand why it is the way it is, to understand what would be a good way > to use it, and what might be a bad way to use it, and therefore to > understand what an API for it should look like, it is good to understand > what use case the protocol was designed for. And that use case was to be > used from browsers. So when you create a WebSocket client, or server, in > any language, it is very valuable to look at the browser provided APIs to > understand how the protocol was intended to be used, and therefore what > features you should expose to users. > > To put in perspective, most server implementations 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 likely that a server implemention either won't > support X, or won't provide very good or easy to use support for X. > Consequently, it's of dubious value to provide a new client where support > for X complicates the API, since servers aren't going to support that well > anyway, it's providing a feature that you won't be able to use at the cost > of making other features harder to use. > > Regards, > > James > >
