W3C home > Mailing lists > Public > public-webrtc@w3.org > December 2012

Re: Move to de-facto error reporting

From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 27 Dec 2012 08:27:22 -0800
Message-ID: <CABcZeBOQn8GRmytaKs8mqBf4hcOzqWv_1gaOQvGpAGO6QNpFoQ@mail.gmail.com>
To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Cc: Travis Leithead <travis.leithead@microsoft.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Dec 26, 2012 at 11:07 PM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 2012-12-21 19:47, Travis Leithead wrote:
>> From: Stefan Håkansson LK
>>> [mailto:stefan.lk.hakansson@**ericsson.com<stefan.lk.hakansson@ericsson.com>]
>>> Travis,
>>> (sorry for the top-posting) at least on a high level I agree fully
>>> (and I think I have said on occasions that we should use
>>> DOMErrors).
>>> Though, I know that it has been argued there are occasions when you
>>> need to know directly if something succeeded or not. One example
>>> that has been brought up is setLocal/Remote. You would like to know
>>> if the application of the offer/answer was successful or not before
>>> sending it off to the peer's UA. I think that is the reason success
>>> and error callbacks are used there rather than error events (since
>>> it would be undefined how long you would wait for a error event
>>> before considering it a success).
>>> I don't know to what extent this can be worked around, as said I
>>> fully support aligning to DOMErrors as far as possibly - but so far
>>> that we lose functionality.
>>> Stefan
>> Actually, this is not a new problem. Applications have a similar need
>> when interacting with Indexed Db--for example, then want to start a
>> request, then once they know a part of the request has succeeded,
>> then the start the next conditional part of the request, etc. For
>> this purpose IndexedDb also includes an onsuccess ("success") event
>> that fires on the request. Note, that due to the asynchronicity of
>> various IndexedDB requests, each request returns a request object
>> upon which the onsuccess handler can be registered. This is very
>> similar to the "promises" async programming pattern.
> I guess we could in principle move to a similar model:
> * getUserMedia could immediately return a MediaStream object with "dead"
> tracks; tracks would then fire events if the user allows the use of devices
> * createOffer/Answer could immediately return an object which in turn
> fires an success event which delivers the actual SDP (or fires an error
> event if something went wrong)
> * setLocal/Remote could lead to that the PeerConnection fires success or
> error events (to allow the application the ensure that things worked out
> before sending the offer/answer)
> * the UA could queue things up to ensure that in a sequence like
> "setRemote(offer), createAnswer" the answer is not created until the offer
> has been applied
> The question is if the gain coming from aligning to the model used by
> IndexedDB is big enough to motivate these changes. I am not sure.

I'm really not following what the advantage of this would be. What use
cases does it
enable that are not available with the current design?

Received on Thursday, 27 December 2012 16:28:31 UTC

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