websockets

[James Roper]

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

On 4 March 2018 at 05:49, Chuck Davis <cjgunzel at gmail.com> wrote:

> 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 for java clients since RMI which was released I think
> in 1.1.  Java WebSocket is NOT for browsers....it's for Java clients!!!!
> ��  And I'm quite pleased with the progress I've made refactoring to use
> the jdk9 WebSocket api together with wildfly11 on the server (and still
> blazingly FAST -- seems to be snappier than jdk8 implementation).  Now if
> the IDEs would get in gear to fully implement jdk9 I'd be in fat city.
>
> And my thanks to everyone who has participated in this particular
> conversation on this list and all the expertise that has been shared.
>
> >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 protocol
> allows beyond this as low level.
>
>>
>> Regards,
>>
>> James
>>
>>
>


-- 
*James Roper*
*Senior Octonaut*

Lightbend <https://www.lightbend.com/> – Build reactive apps!
Twitter: @jroper <https://twitter.com/jroper>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180305/785e8de8/attachment.html>