Skip to main content

[jsr356-experts] Ideas for narrowing scope

  • From: Danny Coward < >
  • To:
  • Subject: [jsr356-experts] Ideas for narrowing scope
  • 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
Danny Coward
Java EE
Oracle Corporation

[jsr356-experts] Ideas for narrowing scope

Danny Coward 10/25/2012

[jsr356-experts] Re: Ideas for narrowing scope

Scott Ferguson 10/26/2012
Please Confirm