On 07/11/2012 08:01 AM, Remy Maucherat wrote:
> On Wed, 2012-07-11 at 09:59 +0100, Mark Thomas wrote:
>>> It is important that the API can deliver partial frames to allow
>>> implementations with a small fixed buffer.
>> I agree there needs to be a way for large messages to be consumed
>> without having to buffer the entire message. Given that there are a lot
>> of APIs that expect streams and that it is much easier to implement
>> chunking / partial frames (or whatever you want to call it) on top of a
>> stream than it is to implement streams on top of chunking / partial
>> frames then I think the underlying implementation should be streams with
>> (optionally) the partial frames implemented on top.
> But the Servlet API provides async IO underneath the websocket
> implementation, so that makes async the default target for the JSR API.
>
"async" is a bit imprecise here, which matters for this discussion.
Async.1: (message callback) the application releases its thread to be
notified when the next data arrives (e.g. between messages). When the
data arrives, the thread is attached and the application reads the data
for the message, e.g. with blocking calls. This is most certainly async.
Point being, the application controls when it wants to use an async
callback and when it wants to use blocking calls, as appropriate. (Some
applications might choose the async in the middle of the message, some
might use blocking.)
Async.2: (datagram) The API _only_ sends partial chunks (with a marker
at the end). It is the responsibility of the application to assemble the
chunks.
Both 1 & 2 are async, but they have different characteristics.
-- Scott