Hi folks,
We've been a bit quite over the last few weeks on the list, so I wanted
to gather everything together into one place, the loose ends, updates to
the spec, so that this is a good place to jump back in.
* Spec Update
I'm about to post out v004 of the spec, which includes javadoc and
(new!) a spec document. This is in preparation for our upcoming Expert
Draft, so now is a good time to read it through, especially if you
skipped earlier versions !
Just a side note: you may see some weird codes in the javadoc and the
spec document: "WSC:24". I'm trying out a new way to help call out
testable statements in the spec so that the compatibility test kit is
easier to create and keep up to date.
* Oracle RI
We're starting work now on the RI, and will start implementing the
features in the API. I'll send out more info when we get to a good point
to look at it. Our hope is to have something in reasonable working shape
against the v004 API in the next few weeks and should give us useful
information on the API as we refine it.
* ByteBuffer vs byte[]
The API now uses ByteBuffer instead of byte[] throughout due to popular
demand :)
* HttpSession
So I think we arrived at a conclusion that we want the HttpSession to be
available to web socket developers, but only at handshake time. Also,
we'd like to try to avoid a hard dependency on the servlet API. Also,
something that came up in this was the need not to directly expose the
ServletRequest/Response in the handshake process to be able to
accommodate extensions like MUX. We're hiding behind our own handshake
request.response objects so I think that will be ok. This is all updated
in the v004 API I posed.
Separately, there's an issue of HttpSession timeout/invalidating and how
it relates to web socket sessions - see my email on security for some
thinking there.
* Supporting MUX / specific web socket extensions
Greg brought up the possibility of supporting MUX in the specification,
which I took to mean the MUX extension which working through its drafts.
Now we have the extension api which allows extensions to be created
separately from and configured into a web socket implementation, and to
'proof' the extension API we're planning on building at least one
extension in the Oracle implementation (probably MUX). However, it does
look like the MUX extension is not finished yet, and the support in
browsers is spotty. So, it makes me a bit hesitant to require anything
in the spec about MUX specifically until its finished.
Does anyone have up to date information about what's likely to change in
the spec, when its expected to be done, and when the browsers have it in
their roadmaps ? Here's the latest draft I see:
http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-05 .
* Annotations for max message size
Greg suggested this and I think it sounds like a good idea, see what you
think in v004.
* Ideas on EE integration
There is a first sketch of integration points with Java EE in the v004
spec document: in summary this is a collection of useful EE things to
inject into web socket applications (like the ServletContext), and a
sketch of what EE components could make Web Socket endpoints (like a
stateless session EJB). Please take a look.
* Small API tweaks
There are a few small tweaks to the API: The API separates out the
different async send modes (by future / by completion handler). See the
diff list I sent out for all the details.
* Web Socket Session active
Bill brought up the issue that we can't really tell if a web socket
connection is active or not without doing something (expensive) on the
network: e.g. session.isActive(). Perhaps we should have a means to
explicitly/expensively check - like a session.checkActive() which sends
a ping and waits for the pong - for developers who judge it cheaper than
attempting to send something only to find it will fail, as well as a
means, like session.getLastActiveTime() marking the time of last
read/write on the connection ?
Thanks,
- Danny
--
<http://www.oracle.com> *Danny Coward *
Java EE
Oracle Corporation