On 11/14/12 5:56 PM, Danny Coward wrote:
> 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
1) This looks good. I just refactored with this change and it works
fine. I assume you're planning on changing URL to String to match the
DefaultClientConfiguration?
2) The proposed server publish is a bit clunky though. In several
services, I wanted the endpoint instances to have shared state. I worked
around it by extending ServerEndpointConfiguration. I think an
EndpointFactory might be cleaner:
interface EndpointFactory<T> {
EndpointConfiguration getConfiguration(); // to match the Endpoint
getConfig() above
T createEndpoint();
}
ServerContainer.publish(EndpointFactory<T> myEndpoint);
-- Scott
>
> - 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
>