W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2014

Bug 26939 "what info does the app get when a track ends" - where are we

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 10 Oct 2014 14:01:59 +0000
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D07E1D3@ESESSMB209.ericsson.se>
There was some discussion on the list (starting at [1]), followed by a 
bug being filed to track this [2].

The few who spoke on this subject on the list seemed to agree that it 
would be a good idea to know the reason. Personally I tend to agree, as 
an app developer I would ask the user for permission again if the track 
ended because of "internal error", while I would not do that if the user 
revoked permissions.

If someone thinks we should really not add this kind of functionality, 
please speak up.

(Not counting Jan-Ivar's Promise-based proposal) there seem to be two 
proposals on the table:

1. Declare the type of interface for "ended" to be 
MediaStreamErrorEvent, and in addition declare the "error" attribute of 
the MediaStreamErrorEvent to be nullable (for the case where there is no 
error)

2. Define a new MediaStreamTrackEnded event, which carries a cause to 
the application (some causes are errors, others not).

What is the view in the task force, do you prefer one over the other (or 
a third alternative)?

If not, the task would be handed over the the Editing team (or someone 
volunteering) to draft a proposal based on their preference for review.

Stefan

[1] 
http://lists.w3.org/Archives/Public/public-media-capture/2014Aug/0200.html
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=26939
Received on Friday, 10 October 2014 14:02:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:50 UTC