Hello experts,
(2012/04/25 8:53), Danny Coward wrote:
> Hi folks,
>
> Thanks for all your comments and suggestions. One thing that has worked well in groups I've been involved with in the past is for me to summarize every so often the most recent discussions. It's helpful to me as a way of making sure I have read everything, and also to expert members that sometimes don't have time to read every email but who need to be able to jump back into the discussion when they do have time.
>
> Here's a first summary of the discussion arising from the requirements document I sent around, your comments welcome, of course.
>
> Support for WebSocket protocol versions ?
>
> Questioning which earlier versions to support. While folks may still in situations be using pre-RFC6455 versions, my guess on that would be that by the time we ship JSR 356 (current schedule: next summer), most browsers and implementations will have moved onto RFC6455, I would propose we require RFC6455 as the earliest version. I expect we'll need some versioning scheme as later versions of the protocol get finalized.
I agree, because RFC6455 is now in Standard Track ("Proposed Standard")
and expected to be "Standard" by final release of JSR 356.
> Relationship with Servlet 3.1
>
> Perhaps the requirement I sent out was confusingly stated as it raised variety of issues ! Perhaps this will help:
>
> - Servlet version: We'd (speaking for our team at Oracle) certainly like to be able to deliver our implementation of the WebSocket API that can run on servlet 3.1 since it is intentionally designing a nice HTTP Upgrade handoff api and perhaps a new async I/O. So, intention of the requirement was a flag not to put something in the WebSocket API to prevent that situation being possible. Now, if others here want to build an implementation that runs on earlier servlet versions, I think that would be goodness too, in which case we should beware of adding things in the spec that would preclude someone building this API on a servlet 2.5 container too.
If earlier servlet versions are supported,
I think spec needs to describe the way to use WebSocket like this:
- JSR 356 provides libraries which implements HTTP upgrade
and async I/O(based on JDK's NIO) as a part of
WebSocket API (isolated from Servlet API).
- WebSocket users need to prepare the libraries by themselves.
> - Does anyone plan on building an implementation of this on a pre-servlet 3.1 container ? If so, which version ?
Servlet 3.0, if possible.
> - API dependency: It was the not intention that this requirement imply that the JSR356 APIs would explicitly depend on the servlet API. (Although I do agree with Justin that exposing the HttpSession probably would be useful, in the situation that the WebSocket API is running in the servlet container.)
>
> - Co-packaging the Web Socket API implementation with EARs/WARs:
>
> I'd certainly not envisioned it like that: I'd expected, as I think Greg and Remy both outlined, that people wanting to support JSR356 in EE would extend the container, with nothing but annotated POJOs in the WAR/EAR. Rather than require co-packaging the implementation as a library with applications. But I think it would be ok if people want to deliver the implementation that way.
>
> Client APIs
>
> So, we have a few strong votes to make sure we deliver a client API in the first version. Good to know ! As someone pointed out, most of the API is symmetrical, save for the handshake. Unless someone has a good reason to support earlier versions of the JDK, I'd suggest we take a baseline of JDK 7 i.e. the client api works on JDK7 and anything above. Does that sound reasonable ?
>
> Content Encoding
>
> It seems clear that developers will want to encode/decode messages. I'd envisioned something relatively simple, along the lines that Scott sketched out, or such as can be found in JAX-RS. But I'm also sympathetic to Justin's point about adding another similar-but-different api for content encoding/decoding for EE developers. And yet leaving developers with just Strings and byte[] arrays doesn't seem right either. I'd like to hear what others think about this.
>
> Message Queuing
>
> I hadn't thought about requiring yet much in this area, except to say that I agree with Scott's point about basic quality of service like: sending a message to a bad peer should not hang the current thread. Does anyone have any other message-queue related thoughts ?
>
> Thanks,
>
> - Danny
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>