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