On 3/25/10 11:11 AM, Anne van Kesteren wrote:
On Wed, 24 Mar 2010 23:08:43 +0100, Olli Pettay
<olli.pet...@helsinki.fi> wrote:
On 3/24/10 11:33 PM, Ian Hickson wrote:
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.
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.
Wait, so when you pass a DOMString you add the number of 16-bit units
and when you pass a ByteArray (or whatever we end up calling it) you add
the number of bytes?
Yeah, I realized that was ugly, see my other email.
API could just say that convert string to UTF-8 and that is reported in
bufferedAmount.
I think what also matters here is how the protocol will evolve.
This is what I'm thinking here all the time, and which is why I don't
want to expose any protocol level things to the API.
Is it
that expectation that send(DOMString) can eventually send very different
things over the wire depending on how the server reacts to the initial
handshake request?
I sure hope not. The protocol should stay simple, if possible.
How do the various options we have evaluate against
the potential scenarios coming out of that?
If the API says that conversion to UTF-8 happens always, that
should work, since possible conversion to something else would happen
in a level lower than the API implementation.
-Olli
