Hello all,
I've posted a version 002 of a draft API for this JSR.
Please can you all take a look next week, by Friday 29th June, and I
will collect up issues/thoughts from you towards the next version.
Since I didn't get much feedback on the first draft, I filled out some
of the areas I highlighted I wanted to work on when I sent out the last
draft (see below).
Example code
<
http://java.net/downloads/websocket-spec/Spec%20javadoc%20Drafts/v002/Version%20002%20Examples.html>
and javadoc
<
http://java.net/projects/websocket-spec/downloads/download/Spec%20javadoc%20Drafts/v002/API%20Doc%20v002.zip>
are posted in the downloads section
<
http://java.net/projects/websocket-spec/downloads/directory/Spec%20javadoc%20Drafts/v002>,
under v002:-
Thanks !
- Danny
Issues covered in v002
* Message representation: The API presents messages as String, byte[]
and Iterators thereof. No nio classes, no IO streams. The goal of this
approach was to allow buffered messages (for convenience) and chunked
messages (for efficiency) without limiting the implementation choices
IO/NIO/combination of implementors of the API.
* Connection modes: Though web socket provides no guarantee of delivery,
the API adds async send modes: the point of completion of the send being
when the message has been completely transmitted (if not necessarily
received).
* The API assumes Pings and Pongs are implementation artifacts, but not
of concern to application developers. So they don't appear.
* The API doesn't expose web socket data framing, though a chunked
approach to message processing is exposed. So implementations get to
choose how to they want to relate the two.
* The server configuration assumes a simple programmatic mapping to URI.
There's a range of possibilities, from static configuration to more
dynamic schemes like in Grizzly. The API hasn't changed since v001 in
this regard.
* There are some simple annotations in this API that map POJOs into
Endpoint objects.
* The API adds session timeouts, and limits on message buffer sizes.
What's missing ?
* Handshake: the API assumes the developer has minimal knowledge of the
details of the handshake process, save for the basic elements of the
URI, optional Origin check, subprotocol preferences. What's missing ?
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation