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