I agree that we need to do something for websockets this iteration of
the servlet spec.
I also agree that trying to get generic upgrade support is probably
the wrong way to go (and a lot of work). Note that SPDY could be
used transparently to a servlet webapp (and already is if you run on
google appengine from chrome), and that there is already some
discussions about websocket over SPDY, so a servlet spec that
supported websockets could potentially work transparently over SPDY.
ie no point trying to make a mechanism that works for both Websockets
and SPDY.
I agree with Remy about his concerns regarding the unlimited message
size in websockets. There are two compelling features of
websockets: 1) bidirectional 2) message based. It is a great pity
that potentially large size of WS messages might push us towards
streaming APIs when the vast majority of currently conceived usage
will be small/medium messages that will easily fit in buffers.
Note also that the browser implementations do not support either frame
or streamed based APIs and they limit their frame size (and I suspect
message size) to <16MB.
http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations
So webapps are not going to see unlimited messages any time soon and
it would be a pity to come up with a more complex than needed API
because of these non existent messages. Having said that, 16MB
buffers are still significant on a server and we may need to have
limits anyway.
By giving a streaming interface to the application, you are just going
to make the application responsible for an extra layer of buffering
and for policing any resource limits. Applications will often have
no idea (or more importantly, often no care) about resource limits
and I suspect that the vast majority of implementations would just
stream the messages into unlimited StringBuilders. With streaming we
would have many many applications vulnerable to simple DOS attacks.
Also note that if limits are exceeded, then the WS connection needs to
be closed with the correct error codes, else clients are likely to
just try again.
It is the job of the container to protect applications from these
kinds of concerns - even if it means that we have to impose some
limits. We already do this with HTTP, where the server imposes a
maximum size on the URI, the headers and often on POST form content.
Just because the HTTP protocol does not limit the size of URIs,
headers or form content does not mean that we went to a stream API for
getPathInfo(), getHeader(String) and getParameter(String).
So I strongly believe that we should offer a simple message based API
(byte[] and String), with limits imposed and enforced by the
container, which will run the correct error conversations and any
negotiations as needed.
regards