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