W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Re: Sending very large chunks over the data channel

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 28 May 2014 15:54:32 +0200
Message-ID: <CALiegf=BiDxT_k37RE0D=x47VZkYkyoyaU4+7CYuZ50mSTT+ug@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
2014-05-28 15:43 GMT+02:00 Harald Alvestrand <harald@alvestrand.no>:
> On 05/28/2014 02:17 PM, Iñaki Baz Castillo wrote:
>>
>> 2014-05-28 14:04 GMT+02:00 Harald Alvestrand <harald@alvestrand.no>:
>>>>
>>>> This is JavaScript land. Why does not the browser just allocate space
>>>> for *all* the data provided in send() calls and deals with EAGAIN and
>>>> similar stuff internally? This is, send() NEVER fails, period. The
>>>> browser holds the data and sends it when it can. The JS code still can
>>>> check the bufferedAmount attribute in order to detect memory leaks due
>>>> to slow sending.
>>>
>>>
>>> That's what the API looks like now. Until it fails, it works.
>>
>> Not the same. I meant "send() MUST never fail".


> http://www.w3.org/TR/XMLHttpRequest/#the-send()-method doesn't agree with
> you.

Wow, it is obvious that those errors have *nothing* to do with what we
were talking about in this thread:

-----------------------
XMLHttpRequest
The send() method

"Throws an "InvalidStateError" exception if the state is not OPENED or
if the send() flag is set."
----------------------

1) Of course any send() method MUST fail if the socket is not open.

2) "The send() flag indicates that the send() method has been invoked.
It is initially unset and is used during the OPENED state."

This is completely different than what I meant! The above two errors
in XMLHttpRequest may happen due to a *bad* JS code. In the other
side, the error in DataChannel.send() may happen in runtime *once* the
socket is open.

Are you really insisting in that both errors are "similar"?


-- 
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Wednesday, 28 May 2014 13:55:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:40 UTC