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

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

From: Jim Barnett <1jhbarnett@gmail.com>
Date: Fri, 10 Oct 2014 10:22:33 -0400
Message-ID: <5437EBA9.1060300@gmail.com>
To: public-media-capture@w3.org
I think it's a bit odd to have a MediaStreamErrorEvent with no error.  
It would be cleaner to have a separate Ended event, where the cause 
might or might not be an error.  Applications will want to know the 
cause, at least in some cases.s

- Jim
On 10/10/2014 10:01 AM, Stefan Håkansson LK wrote:
> 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:23:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:30 UTC