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.
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.
- Does anyone plan on building an implementation of this on a pre-servlet 3.1 container ? If so, which version ?
- 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.
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 ?
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.
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 ?
[jsr356-experts] Re: Summarizing discussion about requirements