I'm also a fan of 3B with 1 layered on top for convenience.
On Thu, Jul 12, 2012 at 6:46 PM, Danny Coward <danny.coward_at_oracle.com>wrote:
> Hi folks,
>
> I'm going try to to reduce the thread on the various options on the
> streaming apis we've chewed on over the last week into three options. I
> *think* everyone agrees that applications should listen for incoming
> messages, rather than block until one arrives. Right ? So I think that
> leaves us with these three modes (below) for processing messages. (And note
> that I think we agree that nothing in the API is supposed to dictate
> anything about how the implementation uses web socket framing underneath.)
>
> mode
> receive description
> possible receive API
> send description
> possible send API
> 1. "whole messages"
> listen for incoming messages, get message all at once onMessage(String
> string)
> onMessage(byte[] bytes)
> send whole messages send(String string)
> send(byte[] bytes)
> 2. "blocking read/writes"
>
>
> listen for incoming messages, read message from stream using blocking
> calls onMessage(InputStream is) { ... byte b = is.read(); ...}
> onMessage(Reader r) { ... int c = r.read(); ... }
> open send stream, blocking writes to the stream OutputStream
> getSendStream()
> Writer getSendWriter()
> 3. "async processing"
>
>
> listen for incoming message, receive message from stream asynchronously Option
> A) onMessage(AsynchronousByteChannel abc) { abc.read(bytebuffer,
> attachment, completionhandler) }
>
> Option B) 1 or more calls to onMessage(String partialString, boolean
> isLast) or onMessage(byte[] partialBytes, boolean isLast)
>
> Option C) servlet 3.1-style special IO streams that allow non-blocking
> reads.
> initiate outgoing message, message pulled on demand by the stream Option
> A) AsynchronousByteChannel getAsyncChannel()
>
> Option B) 1 or more calls to send(String partialString, boolean isLast) or
> send(byte[] partialBytes, boolean isLast).
>
> Option C) servlet 3.1-style special IO streams that allow non-blocking
> writes.
>
>
> So I think in terms of what goes in the JSR API, mode (1) I think is a
> no-brainer for bread and butter applications, although obviously (1) alone
> would not be enough. I think Scott made a good case for (2) in terms of
> making it easy to use other libraries that assume traditional IO. I also
> think we should expose some form of mode (3), for frameworks that build on
> the API. I don't think it has to be either 2 or 3: it can be both.
>
> Of the choices in mode (3), I'd probably go for option A). However, I do
> think many developers (me at least, but not Greg!) find the NIO APIs
> awkward, so can see a benefit in the simplicity of option B). The servlet
> style of specializing the Java IO APIs to allow non-blocking IO seems on
> the face of it to be overly elaborate for our needs, so I like option (c)
> least.
>
> - Danny
> --
> <http://www.oracle.com> * Danny Coward *
> Java EE
> Oracle Corporation
>