Folks - Here's a sketch of a client API. Thankfully, much of the API is
as symmetrical as the protocol, so separating out client-only
functionality should not be too difficult.
So if we say that a client endpoint is one which connects to remote
websocket endpoint awaiting connections on a server and then has a fully
featured web socket conversation it. And the server endpoint is one
which awaits incoming connections from multiple clients and then has
fully featured web socket conversations with all of them.
Then the client profile supports client endpoints, and the server
profile supports the server endpoints *and* client endpoints.
I'm also hearing a couple votes from Jitu and Scott for allowing
annotations to define client endpoints. As currently defined, our
annotations only really work for defining server endpoints.
Is this making sense to everyone ?
If so here's a sketch of what a client annotation might look like:-
ClientWebSocket
URL path(); // full URL to server endpoint
String[] subprotocols() default {}; // the subprotocols the client
wants
Class[] decoders() default {}; // installed decoders
Class[] encoders() default {}; // installed encoders
Of course, this is similar to @WebSocketEndpoint, but not quite the same
semantics meaning for all attributes.
and in terms of arrangement of classes in packages, we could have
a package for all core and client functionality - this would be the
'client-side API'
a package for server-specific functionality - this, together with the
'client API' would be the 'server-side API'
In terms of what we have today, ServerEndpointConfiguration,
DefaultServerConfiguration, ServerContainer, @WebSocketEndpoint,
@WebSocketPathParam, ContainerProvider.getServerContainer() are the
server-specific APIs, everything else is either core or client.
- Danny
On 11/8/12 6:23 PM, Scott Ferguson wrote:
> On 11/7/12 5:59 PM, Danny Coward wrote:
>> OK, so what I'm hearing is we'll drop the extensions, but we're
>> reluctant to defer the client APi to the next relesase.
>>
>> So let me check on what we mean by 'client implementation' before we
>> add what's missing to the API and what kind of separation of
>> packaging we would need.
>>
>> By client implementation we mean a something that runs on the JDK and
>> takes the place of a websocket enabled browser in interacting with
>> websocket endpoint deployed on a server. So the client implementation
>> allows developers to deploy endpoints that connect to a server, send
>> and receive web socket messages one the connection is made. But it
>> doesn't publish web socket endpoints for other web socket clients to
>> connect to. (this is how I am seeing it currently)
>
> Yes, exactly.
>
> As Jitendra's issue report points out, it would be a plus if the
> client can program to the annotation model.
>
> http://java.net/jira/browse/WEBSOCKET_SPEC-51
>
>>
>> Would you expect the web container to support this client API as well
>> ? i.e. do you think that web containers will initiate web socket
>> connections to other web socket peers ? (I'm thinking this is not
>> really a central use case).
>
> Yes. There are lots of services behind the web container: SOA/REST,
> ESB, JMS, custom RMI/Hessian RPC-style remoting, grid stuff, caching, etc.
>
> Many of those kinds of services would be more easily or more
> powerfully implemented with websockets.
>
> -- Scott
>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation