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
--
Joakim Erdfelt <joakim_at_intalio.com>
On Tue, Nov 13, 2012 at 3:56 PM, Danny Coward <danny.coward_at_oracle.com>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
>
>
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>
>
>
>
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>