We are interested in implementing WebSocket as a transport for not only HTTP
Servlet but also SIP Servlet (JSR-289). JSR-289 is based on Servlet 2.5.
So we prefer nothing in JSR-356 that prevents it to be implemented in a HTTP
Servlet 2.5 and SIP Servlet 1.1 container.
Thanks.
- Wei Chen
On 4/24/12 7:53 PM, "Danny Coward" <danny.coward_at_oracle.com> 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.
>
> 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
>
>