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
>