On 11/19/12 10:25 AM, Scott Ferguson wrote:
> 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?
I think what I put in v008 was URI for the path to which the client
connects, and String path for all the server configuration paths because
they can be URI or URI-template.
>
> 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);
Yes, this is an excellent suggestion. I think its a good follow on to
our change of one endpoint instance per connection to have a way to
share state (like an open database connection) across all instances of
the same endpoint.
I was writing up what I seems to be an equivalent formulation that just
uses the EndpointConfiguration. My thinking was that the
EndpointConfiguration and your EndpointFactory are both one instance per
logical endpoint, so was thinking it might be simpler to model what you
have as two separate objects (EndpointConfiguration, EndpointFactory)
with just EndpointConfiguration.
So we would modify EndpointConfiguration's declaration to
EndpointConfiguration<T extends Endpoint>, add your factory method "T
createEndpoint();" to EndpointConfiguration, remove
getEndpointConfiguration() from Endpoint, and have
ServerContainer.publish(EndpointConfiguration myEndpoint);
- Danny
>
> -- 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
>>
>
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation