On 11/9/12 5:50 PM, Scott Ferguson wrote:
> 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)
OK, so allowing non-URL paths sounds reasonable, so we could do
ClientWebSocket
String path(); // full URL to server endpoint or { variable-name }
String[] subprotocols() default {}; // the subprotocols the client
wants
Class[] decoders() default {}; // installed decoders
Class[] encoders() default {}; // installed encoders
and how would we bind the variable-name at runtime ?
- Danny
> 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
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation