Skip to main content

[jsr356-experts] Re: Summarizing discussion about requirements

  • From: IIDA Minehiko < >
  • To:
  • Subject: [jsr356-experts] Re: Summarizing discussion about requirements
  • Date: Wed, 25 Apr 2012 19:14:44 +0900

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
> 




[jsr356-experts] Summarizing discussion about requirements

Danny Coward 04/24/2012

[jsr356-experts] Re: Summarizing discussion about requirements

Greg Wilkins 04/25/2012

[jsr356-experts] Re: Summarizing discussion about requirements

Mark Thomas 04/26/2012

[jsr356-experts] Re: Summarizing discussion about requirements

Wei Chen 04/25/2012

[jsr356-experts] Re: Summarizing discussion about requirements

Remy Maucherat 04/25/2012

[jsr356-experts] Re: Summarizing discussion about requirements

IIDA Minehiko 04/25/2012

[jsr356-experts] Re: Summarizing discussion about requirements

Mark Thomas 04/26/2012
 
 
Close
loading
Please Confirm
Close