On 3/4/10 12:17 PM, Fumitoshi Ukai (鵜飼文敏) wrote:
On Thu, Mar 4, 2010 at 18:52, Olli Pettay <[email protected]
<mailto:[email protected]>> 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?
There might be still a bug there, but fortunately easy to fix one.
Thanks for noticing that.
But I think user of the API might want to know progress while partial
transfer of large messsage,
Indeed.
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.
That would make the JS code a bit uglier and I think JS needs to know if
there are some pending messages.
-Olli
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
