Skip to main content

[jsr356-experts] V003 API for your review

  • From: Danny Coward < >
  • To:
  • Subject: [jsr356-experts] V003 API for your review
  • Date: Fri, 03 Aug 2012 16:43:21 -0700

Hello all,

Thankyou for all your comments over the last few weeks. After a while to digest our later discussions, I've pushed a version 3 of the API for another round of review. This time (in anticipation of some implementation code!) I've both the javadoc up, but also pushed the source code of the api to the repository.

APIdoc bundle: http://java.net/projects/websocket-spec/downloads/directory/Spec%20javadoc%20Drafts/v003
Repo: http://java.net/projects/websocket-spec/sources

Below is a summary of the larger things that changed this round. As usual, please do take a close look at this API and let me know your review comments.

Thanks,

- Danny

Summary of Changes from V002

* Streaming API - this versions adds the whole message callbacks, a blocking stream api and the async api that we seemed to favor. I think this best represents the discussion on the options I laid out, even though it was not conclusive. I'd like to get some implementation experience against this API before we finalize it - especially in terms of how to build the blocking API on top of an asynchronous infrastructure because of some of the doubts raised.

* Pings and Pongs - This version includes the means to send a Ping, listen for Pongs and also send a Pong. I've added a note to include a section in the spec that defines that the implementation
must respond to an incoming Ping with a Pong containing the same data. I can't see any other variables in or policies to apply ton this mechanism after reading sections 5.5.2 and 5.5.3 in the web socket RFC.

* Extensions - This version includes a definition of extensions in the API v3 based a previous discussion. The basic idea is that an extension has a name, a parameter Map and the ability to insert filter like frame-handlers 'underneath' an endpoint. Extensions receieve the frames formulated before them in the implementation and can modify/coalesce/multiply them as they pass them onto the next extension in the chain or back to the implementation - both for outgoing messages and incoming messages. I'm aiming to establish a concept here in the API; I'm expecting lots of feedback on this, especially from those of you who have got into websocket framing and extensions in detail, especially in the area of how to stream data into/out of the data frames.

* Handshake and URI matching
This version reworks handshake API for a number of factors: to encapsulate extension negotiation, expose the http handshake request attributes that we listed out, and allow for http handshake response modification. Please take a look in particular at ServerConfiguration and DefaultServerConfiguration. Its awkward that we do not have readymade HttpRequest, HttpResponse and HttpHeader interfaces in the JDK to reuse to model this, so this version of the api provides homegrown ones.

This version also includes the means, by allowing developers to create their own ServerConfigurations to allow for custom/dynamic URI matching policies other than exact match. I expect we'll want to provide some ready made matching policies, like pattern matching for example, in addition.

* Servlets and cross cutting concerns.

There was a bit of discussion about how this relates to servlets: could these components handle both http and websocket interactions ?

So, here's how I'm seeing it, in terms of the scope of this JSR: this API is focussed mainly on allowing developers to write code that deals with web socket messages and providing the environment for that. The relationship with servlets would be therefore as follows:-

1) Using servlets and/or servlet filters could be a great way of implementing the server side of the websocket handshake and granting the right access to the process. (but is outside the scope of this spec to define how).
2) We hope to build on the new Servlet 3.1 upgrade mechanism in the Oracle RI for websocket. But no-one else has to do so if they do not want to.
3) If developers want to write web applications that have both servlets and websocket components, they absolutely can. They can use the HttpSession and ServletContext (or EJBs !) to share data between the two.
4) And in fact, the new Servlet 3.1 mechanism allows developers create a servlet that handle both regular Http requests and websocket handshake requests, as I thin Joe you had laid out.

I realize this doesn't explain some of other issues raised, like how authentication/authorization will work for websockets and how HttpSession relates to websocket sessions, but I do hope to get to those soon.

- Danny
--
Danny Coward
Java EE
Oracle Corporation


[jsr356-experts] V003 API for your review

Danny Coward 08/03/2012

[jsr356-experts] Re: V003 API for your review

Greg Wilkins 08/08/2012

[jsr356-experts] Re: [jsr356-users] Re: V003 API for your review

Danny Coward 08/09/2012

[jsr356-experts] Re: [jsr356-users] Re: V003 API for your review

Greg Wilkins 08/11/2012
 
 
Close
loading
Please Confirm
Close