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
blocking/non-blocking.
It is important that the API can deliver partial frames to allow
implementations with a small fixed buffer.
-- Scott
>
> Mark
>
>