users@websocket-spec.java.net

[jsr356-users] [jsr356-experts] Ideas for narrowing scope

From: Danny Coward <danny.coward_at_oracle.com>
Date: Wed, 24 Oct 2012 18:16:09 -0700

Hello experts,

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 javascript
client to web server, and may remain that way for some 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.

* 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 e.g.
ServerEndpointConfiguration)
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.

As usual, would like to hear your thoughts.

- Danny
-- 
<http://www.oracle.com> 	*Danny Coward *
Java EE
Oracle Corporation