Skip to main content

[jsr356-experts] Re: [jsr356-users] Re: Client API: was Re: Ideas for narrowing scope

  • From: Scott Ferguson < >
  • To:
  • Subject: [jsr356-experts] Re: [jsr356-users] Re: Client API: was Re: Ideas for narrowing scope
  • Date: Tue, 13 Nov 2012 15:23:42 -0800

On 11/13/12 2:56 PM, Danny Coward wrote:
" type="cite">
On 11/9/12 5:50 PM, Scott Ferguson wrote:
" type="cite">
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

" type="cite">
- Danny

" type="cite">to the connect(), like the connect has now, because the client handler class shouldn't have a hard-coded URL.

-- Scott
" type="cite">

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:
" type="cite">
On 11/7/12 5:59 PM, Danny Coward wrote:
" type="cite">
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

" type="cite">

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




--
Danny Coward
Java EE
Oracle Corporation



--
Danny Coward
Java EE
Oracle Corporation



[jsr356-experts] Re: Ideas for narrowing scope

Greg Wilkins 11/01/2012

[jsr356-experts] Re: Ideas for narrowing scope

Danny Coward 11/03/2012

[jsr356-experts] Re: Ideas for narrowing scope

Justin Lee 11/03/2012

[jsr356-experts] Client API: was Re: Ideas for narrowing scope

Danny Coward 11/08/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Scott Ferguson 11/09/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Danny Coward 11/10/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Scott Ferguson 11/10/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Danny Coward 11/13/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Joakim Erdfelt 11/13/2012

[jsr356-experts] Re: [jsr356-users] Re: Client API: was Re: Ideas for narrowing scope

Scott Ferguson 11/13/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Danny Coward 11/15/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Scott Ferguson 11/19/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Scott Ferguson 11/19/2012

[jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope

Danny Coward 11/22/2012
 
 
Close
loading
Please Confirm
Close