On 07/12/2012 04:25 PM, Danny Coward wrote:
> Hi folks,
>
> I *think* everyone agrees that applications should listen for incoming
> messages, rather than block until one arrives. Right ?
Yep.
> 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.
Sounds good. The (2) "blocking" interface doesn't need to be
java.io.InputStream and java.io.Reader. As long as there's a blocking
read(...) method for the appropriate byte vs char, it should be fine.
For example, a blocking read(ByteBuffer) could also work if that was
preferred by the group.
>
> 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.
I'm not sure I understand how (A) would work. My basic threading mental
model is that following continuation chunks would not be available until
the initial onMessage() returned (to give the illusion of a
single-threaded model). That seems like it would be a bit clunky with A.
-- Scott