[whatwg] WebSocket bufferedAmount includes overhead or not

On 3/25/10 11:11 AM, Anne van Kesteren wrote:
> On Wed, 24 Mar 2010 23:08:43 +0100, Olli Pettay
> <Olli.Pettay at helsinki.fi> wrote:
>> On 3/24/10 11:33 PM, Ian Hickson wrote:
>>> 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.
>>
>> 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.
>
> Wait, so when you pass a DOMString you add the number of 16-bit units
> and when you pass a ByteArray (or whatever we end up calling it) you add
> the number of bytes?
>
Yeah, I realized that was ugly, see my other email.
API could just say that convert string to UTF-8 and that is reported in 
bufferedAmount.

>
> I think what also matters here is how the protocol will evolve.
This is what I'm thinking here all the time, and which is why I don't 
want to expose any protocol level things to the API.

> Is it
> that expectation that send(DOMString) can eventually send very different
> things over the wire depending on how the server reacts to the initial
> handshake request?
I sure hope not. The protocol should stay simple, if possible.


> How do the various options we have evaluate against
> the potential scenarios coming out of that?
If the API says that conversion to UTF-8 happens always, that
should work, since possible conversion to something else would happen
in a level lower than the API implementation.

-Olli

Received on Thursday, 25 March 2010 02:25:59 UTC