- From: <piranna@gmail.com>
- Date: Wed, 7 May 2014 18:15:32 +0200
- To: IƱaki Baz Castillo <ibc@aliax.net>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
>> I would find it better that process gets blocked until the buffer gets >> some space available (it's said, it has send something), > > No way. JavaScript event loop MUST NEVER block. If it blocked all the > web would block (even a mouse click, timers, etc). Just the alert() > call blocks the JavaScript event loop (and you know how "usable" a web > is while displaying an alert) ;) I was just thinking loud... :-) >> or raise an error or throw an exception > > That's the same :) > And yes, the implementation (at least in Chrome) does raise an error > (BTW an undocumented kind of error, of course, as most of the WebRTC > errors...). Why do you think it's the same? This way you know when you can't be able to send data so you can wait a little bit... >> but NO close the channel... Too much agressive to my taste, specially without being able to know how to >> preven it... > > I agree. Anyhow: I've tested that Chrome does NOT close the socket > after raising the error. This is, you can send data after some time on > the same socket. I think this is the correct behaviour, but it would be better to get notified when you can send data again (.send() method returning a promise?).
Received on Wednesday, 7 May 2014 16:16:20 UTC