On Tue, 2012-05-29 at 10:58 -0700, Shing Wai Chan wrote:
> Hi,
>
> We have updated the Servlet 3.1 EDR draft.
> The following is a summary of changes from previous draft:
>
> 1. removing ServletReader and ServletWriter
> as it is hard to get the exact amount of data to be read for
> Readers via the dataAvailable method (in the case of input) and have
> only the Stream based APIs for non-blocking IO. Also since we are
> removing the Reader class we also don't need the dataAvailable method.
> We can rely on the available() method in InputStream.
Ok. Personally I would have left the reader and writer, but most often
async is most useful for lower level stuff, which means bytes.
> 2. renaming the AsyncIOInputSource and AsyncIOOutputSink to
> NonBlockingInputSource and NonBlockingOutputSink
So this is removed.
As a minor detail, I am not convinced by the change from Async -> Non
blocking in the spec document, since this is async IO, but it is not
quite non blocking IO (where, for example, a read with no data is legal,
and returns 0 bytes). Non blocking IO by itself is not very useful
anyway.
> 3. removing inputAvailable and outputReady methods in ProtocolHandler
> as we can use non blocking IO here
After implementing a generic upgrade process in my container (with async
IO), I found out some intricacies (well, broken protocols) which would
require a two phase upgrade process in some cases. The problem is that
some protocols (in conjunction with legacy clients), may need the
generation of invalid HTTP requests (and/or responses). For example,
websockets v0 draft (= old junk) needs it unless protocol specific hacks
are added.
The first call (I named it startUpgrade) allows informing the container
that this is no longer HTTP stuff (although it still should), but that
the request/response needs further processing (reading/writing raw
content) before sending the actual upgrade response to the client.
As another side of the story, the websocket EG does not seem to consider
the "library" use case as being very important. I am quite surprised by
this, to be honest.
--
Remy Maucherat <rmaucher_at_redhat.com>
Red Hat Inc