Looking at the other services API, it looks like at the minimum we need
To implement option # 1 and option # 3c
Where we need synch and asynchronous support. Option #2 seems
To be good but looks complex as the main thread have to be blocked
Until the whole message comes back. I would go with option #2
If we are reading big blog data.
It would be good to extend as some people like the data read byte
By byte for better performance.
Thanks
Naveen
On Jul 12, 2012, at 9:23 PM, Joe Walnes <joe_at_walnes.com> wrote:
> 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
> --
> Danny Coward
> Java EE
> Oracle Corporation
>