On 10/24/12 6:16 PM, Danny Coward
Now that we have a stake in the ground with Early Draft, its a
good point to look at all the things we have defined, and need to
refine and fine tune before we can go final.
We have a lot, and in particular, in view of the shorter timeline
we have to make the Java EE 7 train, I'm looking for some ways to
defer some aspects of what we have to the next release: in part to
increase our (meaning us the expert group's) chances of making a
tight spec, and in part based on our (meaning our team here at
Oracle's) ability to get the implementation and enough testing
done in time. Here are two pieces I think we could defer to a
follow on release.
* Client only API
The first piece I think *could* be deferred is the client API. The
most common deployment scenario for web sockets still looks like
time. The JSR itself describes this piece as something that could
be deferred to a later release. Since the websocket protocol is
largely symmetrical once the connection is established, the API
diff is mostly in initiating the connection and issuing the
handshake. But not having to specify the aspects of the
programming model for standalone client-side JDK as well as the
web container I think will allow us to focus better on the latter.
I'd like to keep the client API if possible.
I'm using it internally for our next internal messaging protocol,
for example. Obviously, I don't need a standard API myself, but the
API has value outside of the browser context.
It can be a secondary focus, if we run out of time, but I'd like to
try to keep it in.
* Extension SPI
The support for extensions in the Early Draft includes support for
web socket extensions in two ways:-
1) The ability to list installed extensions by name, and provide
an extension matching algorithm in the opening handshake. (see
2) The ability to create a (portable) web socket extension written
in Java, and to install it in any JSR 356 implementation. (see,
e.g. Extension, FrameBuilder)
1) is clearly a high priority and I am not proposing removing that
feature. But it does seem that implementations can have their own
mechanisms for writing extensions to the protocol without the
specification having to standardize how, and because we have 1) we
will not be harming the portability of web socket applications on
top of the API. I also have had no feedback on this part of the
Early Draft, which worries me. So 2) seems to me like something we
could defer also.
I'd prefer deferring #2. I'm not sure there's a pressing need for
portable extensions, because the main websocket protocol itself is
powerful enough to support lots of sub-protocols to do the same
thing as an extension. It's probably best to encourage people to use
sub-protocols instead of extensions anyway.
Instead, at least for this version, we can treat the extensions as
server capabilities that the application can select.
As usual, would like to hear your thoughts.
|| Danny Coward