[jsr356-experts] Re: Streaming API: was For Review: v002 API and example code
- From: Mark Thomas <
- Subject: [jsr356-experts] Re: Streaming API: was For Review: v002 API and example code
- Date: Wed, 11 Jul 2012 09:59:20 +0100
On 10/07/2012 23:07, Scott Ferguson wrote:
> On 07/10/2012 11:43 AM, Mark Thomas wrote:
>> On 10/07/2012 17:02, Scott Ferguson wrote:
>>> On 07/10/2012 07:21 AM, Justin Lee wrote:
>>>> I agree with Greg here. The advantage of websockets is the async
>>>> nature and then lends itself well to a callback style interface.
>>>> Trying to shoe horn a blocking API on top of it simply because it's
>>>> what people are used to or it's how the servlet API works are not
>>>> compelling arguments for me at all. Websockets (and the increasingly
>>>> popular SPDY) are fundamentally different ways to communicate and this
>>>> API should reflect that.
>>> The message start is async as the nature of websockets. Reading a
>>> message is not intrinsically async.
>>> It is important to distinguish between the two concepts.
>> +1. This is what Tomcat currently does.
>> However, the maximum frame size for WebSocket distorts things somewhat.
>> As much as I wish that the maximum frame size was much, much smaller, we
>> have to deal with the protocol we have. Therefore, it is somewhat
>> reluctantly that I think we have the ability to handle individual frames
>> in an async manner.
> I don't understand. The frame size doesn't matter for the receiver
> (unless you're implementing mux.) The frame size is not related to
That depends on how the client is (ab)using the protocol.
If the client uses a very large frame size and sends data in drips and
drabs then you have to read the frame using non-blocking if you want the
server to be able to scale.
One could argue that a client behaving in this manner is abusing the
protocol and the client should be sending multiple smaller frames where
the entire frame is sent. If we took that view, then non-blocking
between frames and blocking within a frame is reasonable solution. This
is still my favoured approach but I don't think it is a view that the
rest of the EG supports. I be very happy if I was wrong on that though.
> 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.