On 9/15/11 11:12 AM, Alex Rojkov wrote:
>> Hi All,
>> Before coming up with an API for WebSocket I wanted to have a discussion around what the use cases are for what we want to support in the servlet API. Here are some thoughts I have - but want to get input from the expert group and see where we need to take the API.
> We are very much interested in WebSocket API.
>
> The past WebSocket threads indicate that in this iteration we mainly want a generic upgrade mechanism that could be further specialized to WebSocket API. I think that we should be clear about what this is we are discussing. At the moment I find the requirements list confusing because it deals with the aspects of being a generic (protocol upgrade) and specialized (WebSocket) without clearly demarcating each requirement as generic or specialized.
We would like to have a generic upgrade mechanism so that it can used
for the future HTTP upgrade tokens.
Since WebSocket is the most (only) interesting upgrade token in this
moment, we would like to have specialized APIs for WebSocket, too.
Shing Wai Chan
> For the purpose of feedback I'l assume that we mainly focus on WebSocket RFC(unless there is another candidate to draw generalization from):
>
> At the API level WebSocket should be similar to an async requests so a normal servlet should decide to upgrade to WebSocket, like startAsync; it shouldn't be dispatched automatically and there is no need for a special WebSocketServlet. Additional support for sessions, auth. etc. then becomes unnecessary because the initial ServletRequest will provide that.
>
> "Container requirement to support data framing" implies that some required parts of the RFC could be optional. The item needs to be stricter, as: "implements the WebSocket RFC"
>
> So the WebSocket set of requirements essentially reduces to:
>
> * Support for upgrading a HTTP/servlet request to WebSocket through the servlet API (like startAsync, gives all the Java EE, auth, cookie stuff for free.)
> * Support WebSocket stream-based messaging API (i.e. not exposing framing directly)
>
> Thanks,
> Alex
>
>> • Support for upgrading protocol to WebSocket
>> • Support for messaging constructs that WebSocket has in the Servlet API
>> • Container requirement to support data framing - not exposed to the user in the servlet API
>> • Support for security constraints, authentication and authorization
>> • Support for exposing the sessions, cookies and other java ee constructs like user transaction etc in a websocket application
>> • Add enough support in the servlet API to be able to build a higher level WebSocket API (for example like what we did with JAX-RS).
>> What else am I missing? If there are other requirements, use cases that people think need to be addressed, please let us know.
>>
>> Thanks
>>
>> - Rajiv