Re: Move to de-facto error reporting

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?

-Ekr