Skip to main content

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

  • From: Danny Coward < >
  • To:
  • Cc:
  • Subject: [jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope
  • Date: Wed, 21 Nov 2012 17:40:11 -0800

On 11/19/12 10:25 AM, Scott Ferguson wrote:
" type="cite">
On 11/14/12 5:56 PM, Danny Coward wrote:
" type="cite">
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.
" type="cite">
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



" type="cite">
-- Scott

" type="cite">

- Danny


On 11/13/12 3:23 PM, Scott Ferguson wrote:
" type="cite">
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



--
Danny Coward
Java EE
Oracle Corporation



--
Danny Coward
Java EE
Oracle Corporation


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

(continued)

[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