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
* 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.
[jsr356-experts] Ideas for narrowing scope