On 10/24/12 6:16 PM, Danny Coward wrote:
> 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.
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 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.
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.
- Scott
>
> As usual, would like to hear your thoughts.
>
> - Danny
> --
> <http://www.oracle.com> *Danny Coward *
> Java EE
> Oracle Corporation
>