On 11/9/12 5:08 PM, Danny Coward wrote:
> 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.
I'm assuming the client would use a new ClientContainer.connectToServer
method with a different signature.
That looks fine except for path(). The path needs to be a parameter (or
config object) to the connect(), like the connect has now, because the
client handler class shouldn't have a hard-coded URL.
-- Scott
>
> 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
>