RE: Move to de-facto error reporting

________________________________________
> 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.

-Travis

Received on Saturday, 29 December 2012 16:57:54 UTC