[whatwg] WebSocket bufferedAmount includes overhead or not.

[Olli Pettay]

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?

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).


> 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
>