[whatwg] WebSocket bufferedAmount includes overhead or not

[Erik Möller]

On Thu, 25 Mar 2010 13:23:57 +0100, Olli Pettay <Olli.Pettay at helsinki.fi>  
wrote:

> On 3/25/10 12:08 PM, Niklas Beischer wrote:
>> On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
>> <Olli.Pettay at helsinki.fi> wrote:
>>
>>> On 3/25/10 12:08 AM, Olli Pettay wrote:
>>>> On 3/24/10 11:33 PM, Ian Hickson wrote:
>>>>> On Sun, 21 Feb 2010, Olli Pettay wrote:
>> [snip]
>>>>> I guess I'm unclear on whether bufferedAmount should return:
>>>>>
>>>>> 1. the sum of the count of characters sent?
>>>>> (what would we do when we add binary?)
>>>> I believe this is actually what we want.
>>>> If web developer sends a string which is X long,
>>>> bufferedAmount should report X.
>>>>
>>>> And when we add binary, if buffer which has size Y is
>>>> sent, that Y is added to bufferedAmount.
>>>
>>> Though, this is a bit ugly too.
>>> Mixing 16bit and 8bit data...
>>>
>>> One option is to remove bufferedAmount,
>>> and have just a boolean flag
>>> hasBufferedData.
>>>
>>> Or better could be that the API spec says that WebSocket.send()
>>> converts the data to UTF-8 and bufferedAmount
>>> indicates how much UTF-8 data is buffered.
>>> Then adding support for binary would be easy.
>>> And that way it doesn't matter whether the protocol
>>> actually sends the textual data as UTF-8 or as
>>> something else.
>>>
>>> This way web developer can still check what part of the
>>> data is still buffered. (S)he just have to convert
>>> UTF-16 to UTF-8 in JS, when needed.
>>
>> What about having bufferedAmount represent the number of bytes
>> (including overhead) buffered by the WebSocket,
> The problem here is that how can the API describe what the
> bufferedAmount actually is. And since the underlying protocol
> may change, the values in bufferedAmount may change.
>
>
>
>   for flow control
>> purposes, and adding a new indicator (bufferedMessages) representing the
>> number of messages that are not fully pushed to the network? Since the
>> API is message based there is, besides flow control, little reason to
>> specify how much of a particular message has been sent, right?
>
> Hmm, would it be enough to have just bufferedMessages, and remove
> bufferedAmount.
>
>
> -Olli
>
>
>
>>
>> BR,
>> /niklas
>>
>>
>>>> The reason why I'd like it to work this way is that
>>>> IMO scripts should be able to check whether the data
>>>> they have posted is actually sent over the network.
>>>>
>>>>
>>>> -Olli
>>>>
>>>>
>>>>>
>>>>> 2. the sum of bytes after conversion to UTF-8?
>>>>>
>>>>> 3. the sum of bytes yet to be sent on the wire?
>>>>>
>>>>> I'm not sure how to pick a solution here. It sounds like WebKit  
>>>>> people
>>>>> want 3, and Opera and Mozilla are asking for 2. Is that right? I  
>>>>> guess
>>>>> I'll go with 2 unless more people have opinions.
>>
>>
>

Just to clarify then, the two use cases we're trying to accommodate are:
a) The client wants to be able to limit the data sent over the wire to X  
kb/s.
b) The client wants to make sure some earlier message(s) has been sent  
before queuing a new one.

Is that correct, or are there any other use cases anyone had in mind?

-- 
Erik Möller
Core Developer
Opera Software