[whatwg] WebSocket bufferedAmount includes overhead or not.

[Fumitoshi Ukai (鵜飼文敏)]

On Thu, Mar 4, 2010 at 18:52, Olli Pettay <Olli.Pettay at helsinki.fi> wrote:

> On 3/4/10 4:42 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
>
>> Hi,
>>
>> I noticed that WebSocket spec updated to not inlcude framing overhead in
>> bufferedAmount.
>>
> I asked that since from API point of view it doesn't make
> much sense to have the frame bytes to be magically included in the
> bufferedAmount.
> What if we change the protocol and require different amount framing
> bytes?
> Also why to have framing bytes and not the bytes related to http handling?
>

I think bufferedAmount is a number of bytes are buffered to be sent on wire,
so including frame byte is reasonable.


>
> Also, XHR+progress events don't include http headers etc in the
> .loaded or .total.
>
>
>
>
>> http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html
>> I tried to implement it in WebKit, but found it make hard to implement
>> correctly.
>>
> Not hard at all in gecko's implementation (the patch is still waiting for a
> review and will be possibly updated to include the latest
> changes to the protocol before pushing to hg repo).


I just look over  https://bugzilla.mozilla.org/show_bug.cgi?id=472529
It looks just updating bufferedAmount once a whole message has been sent,
isn't it?
But I think user of the API might want to know progress while partial
transfer of large messsage, so this implementation isn't so happy, IMO.

Anyway, if this level of feedback is ok, it would be better to have onsent
event listener to fire after each message has been sent.
Then, we don't need to poll bufferedAmount as do in example in WebSocket API
draft.
What do you think?

-- 
ukai


>
>
>  https://bugs.webkit.org/show_bug.cgi?id=35571
>> It's easy after WebSocket is closed (just add length of message),
>>
> right
>
>
>
>  but
>> while it's open, we'll manage buffer including frame bytes
>>
> In the patch for gecko there is a different buffer for each
> "message", so it is easy to count how many frame bytes are in the
> buffers.
>
>
>
>  and
>> underlying socket will write arbitrary length of the buffer (may not be
>> on frame boundary)
>> To get bufferdAmount correctly without framing overhead, we need to
>> parse the buffer again.  It's not light operation and it's challenge to
>> make it effective.
>> I think including frame overhead is much easier.
>>
>
>
>  Could you revert it?
>>
> That would make the API worse, especially for web developers, IMO.
> They shouldn't need to know about the protocol, they should just be able to
> use the API and understand easily what bufferedAmount means.
>
>
>
> br,
>
>
> -Olli
>
>
>
>
>> --
>> Fumitoshi Ukai
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100304/9a27d1a5/attachment-0001.htm>