Re: Move to de-facto error reporting

On 2012-12-29 17:57, Travis Leithead wrote:
>
>
> ________________________________________
>> From: Stefan Håkansson LK [stefan.lk.hakansson@ericsson.com] On
>> 2012-12-27 17:27, Eric Rescorla wrote:
>>>
>>> On Wed, Dec 26, 2012 at 11:07 PM, Stefan Håkansson LK wrote:
>>>
>>> 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.
>
> My motivation was noting the duplication of very similar error
> objects across the three proposed specs. Since these objects all
> introduce new surface area to the type system of the web platform
> (which are basically redundant), it seemed to be prudent to see if
> there was a better pattern available. It seems there is another
> pattern available, but it has a high relative spec cost (API
> shape/behavior updates) to make happen. At least with getUserMedia,
> I'll note that we are already planning to do something like Steven
> proposed with the synchronous getUserMedia changes. I'd recommend
> that the Recording API make the switch now (while it's early). As for
> the Peer Connection design, while I'd love to see it migrate, it may
> not be worth the cost.

I think that aligning gUM and Recording makes a lot of sense. 
PeerConnection should probably not be changed. Apart from the cost doing 
it, I think we would actually lose some functionality. In the current 
design, if you have different code segments doing 
"createOffer-modifyOffer-setLocal" for different updates of the session 
you could have tailored handling of successes/errors. This may not be 
that straightforward if all you have is success/error events.

>
> -Travis
>

Received on Sunday, 30 December 2012 07:11:11 UTC