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

Re: Move to de-facto error reporting

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Thu, 27 Dec 2012 21:13:58 +0100
Message-ID: <50DCAC06.2060404@ericsson.com>
To: Eric Rescorla <ekr@rtfm.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 2012-12-27 17:27, Eric Rescorla wrote:
> On Wed, Dec 26, 2012 at 11:07 PM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto: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
>             <mailto: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?

It enables no new use cases AFAIK - the advantage would be alignment 
with how errors are dealt with in other newer web APIs. I'm skeptical to 
doing these changes - I just wanted to point out that we could in 
principle align.

> -Ekr
Received on Thursday, 27 December 2012 20:14:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:14 UTC