Re: Move to de-facto error reporting

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:29 UTC