Skip to main content

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

  • From: Joakim Erdfelt < >
  • To:
  • Cc:
  • Subject: [jsr356-experts] Re: Client API: was Re: Ideas for narrowing scope
  • Date: Tue, 13 Nov 2012 16:08:42 -0700

Trivial niggle on syntax.

From:
    Class[] decoders() default {}; // installed decoders
    Class[] encoders() default {}; // installed encoders

To:
    Class<? extends Decoder>[] decoders() default {}; // installed decoders
    Class<? extends Encoder>[] encoders() default {}; // installed encoders

--



On Tue, Nov 13, 2012 at 3:56 PM, Danny Coward < " target="_blank"> > wrote:
On 11/9/12 5:50 PM, Scott Ferguson wrote:
On 11/9/12 5:08 PM, Danny Coward wrote:
Folks - Here's a sketch of a client API. Thankfully, much of the API is as symmetrical as the protocol, so separating out client-only functionality should not be too difficult.

So if we say that a client endpoint is one which connects to remote websocket endpoint awaiting connections on a server and then has a fully featured web socket conversation it.  And the server endpoint is one which awaits incoming connections from multiple clients and then has fully featured web socket conversations with all of them.

Then the client profile supports client endpoints, and the server profile supports the server endpoints *and* client endpoints.

I'm also hearing a couple votes from Jitu and Scott for allowing annotations to define client endpoints. As currently defined, our annotations only really work for defining server endpoints.

Is this making sense to everyone ?

If so here's a sketch of what a client annotation might look like:-

ClientWebSocket
    URL path();  // full URL to server endpoint
    String[] subprotocols() default {};  // the subprotocols the client wants
    Class[] decoders() default {}; // installed decoders
    Class[] encoders() default {}; // installed encoders

Of course, this is similar to @WebSocketEndpoint, but not quite the same semantics meaning for all attributes.

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 ?

- 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




--
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