On Tue, 2012-04-24 at 16:53 -0700, 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.
Given the release date of EE7, I would think only supporting the RFC
officially would be acceptable (although it is likely the API would work
with any version).
> 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 the implementation is part of the container, then it should be
decoupled from the Servlet version. If (assuming it is still a goal) the
implementation can also be used as a library, then it will have to
require Servlet 3.1.
> - Does anyone plan on building an implementation of this on a
> pre-servlet 3.1 container ? If so, which version ?
3.0 only, but the container has a lot of the features that could be in
3.1 (upgrade, async IO). I would not implement it with blocking IO.
> - 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.)
I can also mention that everyone asks for the HTTP session access.
> - 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.
That's the plan Rajiv had. Otherwise, there's no point in adding the
upgrade mechanism in Servlet 3.1.
Note: For annotation processing by libraries (like JSF), the Servlet
container initializer mechanism was added.
> 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 ?
Ok.
> 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 ?
Makes sense.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc