[whatwg] WebSocket bufferedAmount includes overhead or not

On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking <jonas at sicking.cc> wrote:
>
> On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Tue, 23 Mar 2010, Anne van Kesteren wrote:
>>>
>>> We (Opera) would prefer this too. I.e. to not impose details of the
>>> protocol on the API.
>>
>> If we're exposing nothing from the protocol, does that mean we shouldn't
>> be exposing that the string converts to UTF-8 either?
>
> While exposing the fact that strings are sent as UTF-8 does say
> something about the protocol, I think it's still much more protocol
> independent than including the message headers. The string has to be
> serialized in some way, and it seems unlikely that any newly developed
> protocol in the foreseeable future would use anything other than UTF-8
> as serialization.

True, but if bufferedAmount does not byte for byte (or character for
character) match what is fed to the API, what does a few bytes
representing the current overhead matter? IIRC EcmaScript uses UTF-16,
which means that serialization will in most cases make the number of
actually buffered bytes differ from the number of bytes in the original
message buffer. And just because we currently use UTF-8 for
serialization doesn't mean that will always be the case. Thus API users
cannot rely on performing their own conversion to UTF-8 just to find out
exactly how many characters in their message have been sent.

The fact remains that, unless we want to force implementors of the
protocol to match each byte sent over the network with a specific
character in the original message handed to the API, bufferedAmount cannot
represent something unaffected by the protocol. And if we allow
bufferedAmount to be affected by the protocol, why not let it be decided
by the implementation whether or not to include protocol overhead?

As Boris Zbarsky suggested earlier in this thread it might be an idea to
not over-specify this particular part of the API.

BR,
  /niklas


-- 
Niklas Beischer
Software Developer
Opera Software

Received on Tuesday, 30 March 2010 01:51:40 UTC