On Thu, Mar 4, 2010 at 18:52, Olli Pettay <span dir="ltr"><<a href="mailto:Olli.Pettay@helsinki.fi">Olli.Pettay@helsinki.fi</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On 3/4/10 4:42 AM, Fumitoshi Ukai (鵜飼文敏) wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I noticed that WebSocket spec updated to not inlcude framing overhead in<br>
bufferedAmount.<br>
</blockquote></div>
I asked that since from API point of view it doesn't make<br>
much sense to have the frame bytes to be magically included in the bufferedAmount.<br>
What if we change the protocol and require different amount framing<br>
bytes?<br>
Also why to have framing bytes and not the bytes related to http handling?<br></blockquote><div><br></div><div>I think bufferedAmount is a number of bytes are buffered to be sent on wire, so including frame byte is reasonable.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Also, XHR+progress events don't include http headers etc in the<br>
.loaded or .total.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html" target="_blank">http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html</a><br>
I tried to implement it in WebKit, but found it make hard to implement<br>
correctly.<br>
</blockquote></div>
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<br>
changes to the protocol before pushing to hg repo).</blockquote><div><br></div><div>I just look over  <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=472529">https://bugzilla.mozilla.org/show_bug.cgi?id=472529</a></div>

<div>It looks just updating bufferedAmount once a whole message has been sent, isn't it?</div><div>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.</div>

<div><br></div><div>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.</div><div>Then, we don't need to poll bufferedAmount as do in example in WebSocket API draft.</div>

<div>What do you think?</div><div><br></div><div>-- </div><div>ukai</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<a href="https://bugs.webkit.org/show_bug.cgi?id=35571" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=35571</a><br>
It's easy after WebSocket is closed (just add length of message),<br>
</blockquote></div>
right<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but<br>
while it's open, we'll manage buffer including frame bytes<br>
</blockquote></div>
In the patch for gecko there is a different buffer for each<br>
"message", so it is easy to count how many frame bytes are in the<br>
buffers.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
and<br>
underlying socket will write arbitrary length of the buffer (may not be<br>
on frame boundary)<br>
To get bufferdAmount correctly without framing overhead, we need to<br>
parse the buffer again.  It's not light operation and it's challenge to<br>
make it effective.<br>
I think including frame overhead is much easier.<br>
</blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Could you revert it?<br>
</blockquote></div>
That would make the API worse, especially for web developers, IMO.<br>
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>
<br>
<br>
<br>
br,<br>
<br>
<br>
-Olli<br>
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
--<br>
Fumitoshi Ukai<br>
<br>
</blockquote>
<br>
</blockquote></div><br>