On 3/25/10 4:25 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 13:23:57 +0100, Olli Pettay
<olli.pet...@helsinki.fi> wrote:
On 3/25/10 12:08 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
<olli.pet...@helsinki.fi> wrote:
On 3/25/10 12:08 AM, Olli Pettay wrote:
On 3/24/10 11:33 PM, Ian Hickson wrote:
On Sun, 21 Feb 2010, Olli Pettay wrote:
[snip]
I guess I'm unclear on whether bufferedAmount should return:
1. the sum of the count of characters sent?
(what would we do when we add binary?)
I believe this is actually what we want.
If web developer sends a string which is X long,
bufferedAmount should report X.
And when we add binary, if buffer which has size Y is
sent, that Y is added to bufferedAmount.
Though, this is a bit ugly too.
Mixing 16bit and 8bit data...
One option is to remove bufferedAmount,
and have just a boolean flag
hasBufferedData.
Or better could be that the API spec says that WebSocket.send()
converts the data to UTF-8 and bufferedAmount
indicates how much UTF-8 data is buffered.
Then adding support for binary would be easy.
And that way it doesn't matter whether the protocol
actually sends the textual data as UTF-8 or as
something else.
This way web developer can still check what part of the
data is still buffered. (S)he just have to convert
UTF-16 to UTF-8 in JS, when needed.
What about having bufferedAmount represent the number of bytes
(including overhead) buffered by the WebSocket,
The problem here is that how can the API describe what the
bufferedAmount actually is. And since the underlying protocol
may change, the values in bufferedAmount may change.
Easy. The bufferedAmount is: "The amount of bytes waiting to be
transferred, including protocol overhead".
That doesn't define exactly what the bufferedAmount means and what
kinds of values are expected.
What I'd expect the API to tell me is, for example, that if I call
ws.send(foo), and nothing is yet sent over the network, what is the
exact value of bufferedAmount.
Again, I'd really wish to keep the API to work reasonable similar
way as XHR+progress events where protocol overhead isn't reported.
-Olli
It is in this form purely
informational and only intended to let the API user know if there is any
point in trying to send more messages before waiting for more data to be
transferred. Simply put, for flow control purposes.
for flow control
purposes, and adding a new indicator (bufferedMessages) representing the
number of messages that are not fully pushed to the network? Since the
API is message based there is, besides flow control, little reason to
specify how much of a particular message has been sent, right?
Hmm, would it be enough to have just bufferedMessages, and remove
bufferedAmount.
Well, yes. But that would leave it up to the API user to remember how
big the messages sent were if he/she wants to add flow control and avoid
having the buffers inside the WebSocket grow beyond reason.
BR,
/niklas
The reason why I'd like it to work this way is that
IMO scripts should be able to check whether the data
they have posted is actually sent over the network.
-Olli
2. the sum of bytes after conversion to UTF-8?
3. the sum of bytes yet to be sent on the wire?
I'm not sure how to pick a solution here. It sounds like WebKit
people
want 3, and Opera and Mozilla are asking for 2. Is that right? I
guess
I'll go with 2 unless more people have opinions.
