OK, how about:-
Bootstrap API
ClientContainer.connectToServer(Endpoint e) // Endpoint carries own
config object which includes the URL
ClientContainer.connectToServer(Object pojo, URL path) // pojo
deployment, absolute URL separated from POJO/annotation
Annotation ClientWebSocket
String[] subprotocols() default {}; // the subprotocols the client
wants
Class<? extends Decoder>[] decoders() default {}; // installed
decoders (thanks Joakim for generifying this)
Class<? extends Encoder>[] encoders() default {}; // installed encoders
- Danny
On 11/13/12 3:23 PM, Scott Ferguson wrote:
> On 11/13/12 2:56 PM, Danny Coward wrote:
>> On 11/9/12 5:50 PM, Scott Ferguson wrote:
>>>
>>> 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 ?
>
> Maybe I misunderstand. I'm assuming the annotations would be used
> together with ClientContainer like:
>
> ClientContainer.connectToServer(Object endpoint,
> ClientEndpointConfiguration config);
>
> Or maybe something simpler like
>
> ClientContainer.connectToServer(URI url, Object endpoint);
>
> So the annotations on the class aren't used for the server's URL.
> Instead, the URL is a required parameter to connectToServer().
>
> Because it doesn't make sense to me to tie the client class to a
> specific server URL.
>
> -- Scott
>
>>
>> - 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
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation