On Thu, Apr 8, 2010 at 5:22 AM, Niklas Beischer wrote:
> On Fri, 02 Apr 2010 20:43:57 +0300, Jonas Sicking wrote:
>
>> On Thu, Apr 1, 2010 at 8:15 PM, Boris Zbarsky wrote:
>>>
>>> On 3/31/10 6:57 PM, Jonas Sicking wrote:
I would expect that send() is allowed to start streaming data ove
On Fri, 02 Apr 2010 20:43:57 +0300, Jonas Sicking wrote:
On Thu, Apr 1, 2010 at 8:15 PM, Boris Zbarsky wrote:
On 3/31/10 6:57 PM, Jonas Sicking wrote:
I would expect that send() is allowed to start streaming data over the
network as soon as it can, but only update bufferedAmount from the
ev
On Thu, Apr 1, 2010 at 8:15 PM, Boris Zbarsky wrote:
> On 3/31/10 6:57 PM, Jonas Sicking wrote:
>>
>> I would expect that send() is allowed to start streaming data over the
>> network as soon as it can, but only update bufferedAmount from the
>> event loop.
>
> Maybe I'm not being clear. Let's sa
On 3/31/10 6:57 PM, Jonas Sicking wrote:
I would expect that send() is allowed to start streaming data over the
network as soon as it can, but only update bufferedAmount from the
event loop.
Maybe I'm not being clear. Let's say bufferedAmount were to reflect the
number of UTF-8-encoded bytes
On Thu, Apr 1, 2010 at 12:33 AM, Niklas Beischer wrote:
> On Thu, 01 Apr 2010 00:44:57 +0300, Jonas Sicking wrote:
>
>> On Tue, Mar 30, 2010 at 11:06 PM, Niklas Beischer wrote:
>>>
>>> On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking
>>> wrote:
>>>
On Tue, Mar 30, 2010 at 1:51 AM, Niklas
On Thu, 01 Apr 2010 00:44:57 +0300, Jonas Sicking wrote:
On Tue, Mar 30, 2010 at 11:06 PM, Niklas Beischer wrote:
On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking
wrote:
On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer wrote:
On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking
wrote:
On Wed, Mar 31, 2010 at 3:16 PM, Boris Zbarsky wrote:
> On 3/31/10 2:38 AM, Jonas Sicking wrote:
>>
>> I would have expected bufferedAmount to only change as a result of an
>> event being posted to the main event loop. We generally try to avoid
>> "racy" variables since people don't expect them. C
On 3/31/10 2:38 AM, Jonas Sicking wrote:
I would have expected bufferedAmount to only change as a result of an
event being posted to the main event loop. We generally try to avoid
"racy" variables since people don't expect them. Consider for example
if (ws.bufferedAmount> X) {
setUpSomeState
On Tue, Mar 30, 2010 at 11:20 PM, Niklas Beischer wrote:
> On Wed, 31 Mar 2010 09:38:21 +0300, Jonas Sicking wrote:
>
>> On Tue, Mar 30, 2010 at 9:56 PM, Boris Zbarsky wrote:
>>>
>>> On 3/30/10 10:22 AM, Jonas Sicking wrote:
Making it implementation dependent is likely to lead to websi
On Tue, Mar 30, 2010 at 11:06 PM, Niklas Beischer wrote:
> On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking wrote:
>
>> On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer wrote:
>>>
>>> On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking
>>> wrote:
On Wed, Mar 24, 2010 at 2:33 PM, Ian Hi
On Wed, 31 Mar 2010 09:38:21 +0300, Jonas Sicking wrote:
On Tue, Mar 30, 2010 at 9:56 PM, Boris Zbarsky wrote:
On 3/30/10 10:22 AM, Jonas Sicking wrote:
Making it implementation dependent is likely to lead to website
incompatibilities. Such as:
ws = new WebSocket(...);
ws.onopen = function
On Tue, 30 Mar 2010 17:22:07 +0300, Jonas Sicking wrote:
On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer wrote:
On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking
wrote:
On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson wrote:
On Tue, 23 Mar 2010, Anne van Kesteren wrote:
We (Opera) would
On Tue, Mar 30, 2010 at 9:56 PM, Boris Zbarsky wrote:
> On 3/30/10 10:22 AM, Jonas Sicking wrote:
>>
>> Making it implementation dependent is likely to lead to website
>> incompatibilities. Such as:
>>
>> ws = new WebSocket(...);
>> ws.onopen = function() {
>> ws.send(someString);
>> if (ws.bu
On 3/30/10 10:22 AM, Jonas Sicking wrote:
Making it implementation dependent is likely to lead to website
incompatibilities. Such as:
ws = new WebSocket(...);
ws.onopen = function() {
ws.send(someString);
if (ws.bufferedAmount> X) {
doStuff();
Can bufferedAmount not change due to d
On Tue, Mar 30, 2010 at 1:51 AM, Niklas Beischer wrote:
> On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking wrote:
>>
>> On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson wrote:
>>>
>>> On Tue, 23 Mar 2010, Anne van Kesteren wrote:
We (Opera) would prefer this too. I.e. to not impose detail
On Tue, 30 Mar 2010 09:19:33 +0300, Jonas Sicking wrote:
On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson wrote:
On Tue, 23 Mar 2010, Anne van Kesteren wrote:
We (Opera) would prefer this too. I.e. to not impose details of the
protocol on the API.
If we're exposing nothing from the protocol,
On Wed, Mar 24, 2010 at 2:33 PM, Ian Hickson wrote:
> On Tue, 23 Mar 2010, Anne van Kesteren wrote:
>>
>> We (Opera) would prefer this too. I.e. to not impose details of the
>> protocol on the API.
>
> If we're exposing nothing from the protocol, does that mean we shouldn't
> be exposing that the
On Mar 25, 2010, at 4:50 PM, Ian Hickson wrote:
It seems that the consensus is now leaning towards changing the spec
again
to include the overhead, but I haven't changed it yet because I
don't want
to be flip-flopping back and forth -- if we change this, I don't
want to
change it back. I t
On 3/25/10 11:55 AM, Anne van Kesteren wrote:
Why? Progress events are completely different from this. This is about
not saturating the network with too much data; it makes sense if the
actual amount of data that is going to hit the network is known.
Please define "actual amount of data" and "n
On 3/25/10 5:50 PM, Ian Hickson wrote:
What would the use case be for the second one? As far as I'm aware there's
only one use case here: making it possible to saturate the network but not
over-saturate it (i.e. to send data at the exact rate that the network can
take it, without getting behind b
On Fri, 26 Mar 2010, Perry Smith wrote:
>
> I'm a little confused. I sent out a rather long reply that no one
> replied to. Did it get put into everyone's spam bucket?
I thought I replied to your e-mail in my omnibus reply on the subject...
did I miss a salient point?
> There is no way that
On Mar 26, 2010, at 4:24 AM, Olli Pettay wrote:
On 3/25/10 11:50 PM, Ian Hickson wrote:
It seems that the consensus is now leaning towards changing the
spec again
to include the overhead,
Well, what if the overhead isn't buffered? What if the implementation
just buffers the bytes from send
On 3/25/10 11:50 PM, Ian Hickson wrote:
(If you haven't posted on this thread before, please see the bottom of
this e-mail -- I'm still looking for more opinions.)
On Thu, 25 Mar 2010, Niklas Beischer wrote:
What about having bufferedAmount represent the number of bytes
(including overhead) b
(If you haven't posted on this thread before, please see the bottom of
this e-mail -- I'm still looking for more opinions.)
On Thu, 25 Mar 2010, Niklas Beischer wrote:
>
> What about having bufferedAmount represent the number of bytes
> (including overhead) buffered by the WebSocket, for flow
On 3/25/10 5:55 PM, Anne van Kesteren wrote:
On Thu, 25 Mar 2010 16:35:19 +0100, Olli Pettay
wrote:
On 3/25/10 4:25 PM, Niklas Beischer wrote:
Easy. The bufferedAmount is: "The amount of bytes waiting to be
transferred, including protocol overhead".
That doesn't define exactly what the buffer
On Mar 25, 2010, at 10:55 AM, Anne van Kesteren wrote:
On Thu, 25 Mar 2010 16:35:19 +0100, Olli Pettay > wrote:
On 3/25/10 4:25 PM, Niklas Beischer wrote:
Easy. The bufferedAmount is: "The amount of bytes waiting to be
transferred, including protocol overhead".
That doesn't define exactly wha
On Thu, 25 Mar 2010 16:35:19 +0100, Olli Pettay
wrote:
On 3/25/10 4:25 PM, Niklas Beischer wrote:
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 e
On 3/25/10 4:25 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 13:23:57 +0100, Olli Pettay
wrote:
On 3/25/10 12:08 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
wrote:
On 3/25/10 12:08 AM, Olli Pettay wrote:
On 3/24/10 11:33 PM, Ian Hickson wrote:
On Sun, 21
On Thu, 25 Mar 2010 13:23:57 +0100, Olli Pettay
wrote:
On 3/25/10 12:08 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
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 gu
On Thu, 25 Mar 2010 13:23:57 +0100, Olli Pettay
wrote:
On 3/25/10 12:08 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
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 gu
On 3/25/10 12:08 PM, Niklas Beischer wrote:
On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
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.
On Thu, 25 Mar 2010 10:21:10 +0100, Olli Pettay
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?
(
On 3/25/10 11:11 AM, Anne van Kesteren wrote:
On Wed, 24 Mar 2010 23:08:43 +0100, Olli Pettay
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 beli
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:
I propose that bufferedAmount doesn't take account the bits added by the
protocol. This way if the protocol is later changed, web developers
don't need to change their code b
On Wed, 24 Mar 2010 23:08:43 +0100, Olli Pettay
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
On 3/24/10 11:33 PM, Ian Hickson wrote:
On Sun, 21 Feb 2010, Olli Pettay wrote:
I propose that bufferedAmount doesn't take account the bits added by the
protocol. This way if the protocol is later changed, web developers
don't need to change their code because of the way they rely on
bufferedAm
On Sun, 21 Feb 2010, Olli Pettay wrote:
>
> I propose that bufferedAmount doesn't take account the bits added by the
> protocol. This way if the protocol is later changed, web developers
> don't need to change their code because of the way they rely on
> bufferedAmount.
On Thu, 4 Mar 2010, Fum
On Tue, 23 Mar 2010 10:38:27 +0100, Olli Pettay
wrote:
And I certainly prefer the current behavior, where the API is not
so tightly bound to the protocol, and where the bufferedAmount is
handled more close to what progress events do with XMLHttpRequest.
We (Opera) would prefer this too. I.e.
On 3/18/10 2:15 AM, Alexey Proskuryakov wrote:
On 05.03.2010, at 15:32, Alexey Proskuryakov wrote:
for something no one should care about, as you
implied above.
From API perspective I do care. Web developers shouldn't need to know
about the protocol, yet (s)he should be able to understand wha
On 05.03.2010, at 15:32, Alexey Proskuryakov wrote:
for something no one should care about, as you
implied above.
From API perspective I do care. Web developers shouldn't need to know
about the protocol, yet (s)he should be able to understand what
bufferedAmount means.
An explanation like "i
On 05.03.2010, at 13:17, Olli Pettay wrote:
for something no one should care about, as you
implied above.
From API perspective I do care. Web developers shouldn't need to know
about the protocol, yet (s)he should be able to understand what
bufferedAmount means.
An explanation like "it's how
On 3/5/10 11:13 PM, Alexey Proskuryakov wrote:
On 05.03.2010, at 12:56, Olli Pettay wrote:
And you're saying that javascript really needs to know about the
frame boundary bytes to detect if it is streaming too fast.
Doesn't sound likely to me.
OK
That's true, but I don't know how many of t
On 05.03.2010, at 12:56, Olli Pettay wrote:
And you're saying that javascript really needs to know about the
frame boundary bytes to detect if it is streaming too fast.
Doesn't sound likely to me.
OK
That's true, but I don't know how many of these have already been
sent
unless I perform l
On 3/5/10 10:39 PM, Alexey Proskuryakov wrote:
On 05.03.2010, at 10:27, Olli Pettay wrote:
I was going to mention this as the primary reason why frame bytes should
be included. JavaScript code needs this information for flow control,
Why?
I assume you are asking why JavaScript code needs th
On 05.03.2010, at 10:27, Olli Pettay wrote:
I was going to mention this as the primary reason why frame bytes
should
be included. JavaScript code needs this information for flow control,
Why?
I assume you are asking why JavaScript code needs this information for
flow control.
My recoll
On 3/5/10 7:54 PM, Alexey Proskuryakov wrote:
On 04.03.2010, at 1:52, Olli Pettay wrote:
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 includ
On 04.03.2010, at 1:52, Olli Pettay wrote:
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 chang
On 3/4/10 12:17 PM, Fumitoshi Ukai (鵜飼文敏) wrote:
On Thu, Mar 4, 2010 at 18:52, Olli Pettay mailto:olli.pet...@helsinki.fi>> wrote:
On 3/4/10 4:42 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
Hi,
I noticed that WebSocket spec updated to not inlcude framing
overhead in
bu
On Thu, Mar 4, 2010 at 18:52, Olli Pettay 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 fra
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
Hi,
I noticed that WebSocket spec updated to not inlcude framing overhead in
bufferedAmount.
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. https://bugs.webkit.org/show_bug.cgi?id=35571
51 matches
Mail list logo
