- From: Dan Burnett <dburnett@voxeo.com>
- Date: Tue, 8 Dec 2015 14:59:50 -0500
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- Cc: "public-media-capture@w3.org" <public-media-capture@w3.org>
On Dec 8, 2015, at 5:09 AM, Kostiainen, Anssi wrote: > Hi, > > Thanks for putting the extensibility guidelines together. > > I've opened an issue [1] for mediacapture-depth to ensure we'll review and implement these guidelines in the depth spec properly. Excellent. Again, these are just guidelines (helps, not prescriptive). > > I'd be fine to land the below text to the Editor's Draft as the initial input to the Extensibility section, to be improved upon based on feedback from real-world users (other specs extending the mediacapture-main). Thanks Anssi! > > As a future improvement I'd add some inline WebIDL where applicable similarly to [2]. I am concerned that this would be viewed as more prescriptive than we agreed we wanted during the TPAC discussions. However, as you point out we can land the current text to get started and then discuss WebIDL as desired. > > Thanks, > > -Anssi > > [1] https://github.com/w3c/mediacapture-depth/issues/92 > [2] https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#extensibility > > >> On 03 Dec 2015, at 16:40, Dan Burnett <dburnett@voxeo.com> wrote: >> >> Group, >> >> Based on the contents of issue #244 [1] and our discussion at TPAC [2,3], I have written an almost completely new proposal for text on extensibility to go into the Media Capture and Streams spec. Please review and comment. >> >> -- dan >> >> [1] https://github.com/w3c/mediacapture-main/issues/244 >> [2] http://www.w3.org/2015/10/28-webrtc-minutes#item09 >> [3] my own notes >> >> =============================== PROPOSED TEXT =============================== >> This section is informative. >> Although new versions of this specification may be produced in the future, it is also expected that other standards will need to define new capabilities that build upon those in this specification. The purpose of this section is to provide guidance to creators of such extensions. >> >> Any WebIDL-defined interfaces, methods, or attributes in the specification may be extended. Two likely extension points are defining a new media type and defining a new constrainable property. >> >> >> = Defining a new media type (beyond the existing Audio and Video types) = >> >> At a minimum, defining a new media type would require >> * adding a new getXXXXTracks() method for the type to the MediaStream interface, >> * describing what a muted or disabled track of that type will render (sec 4.3.1), >> * adding the new type as an additional legal value for the kind atttribute on the MediaStreamTrack interface, >> * updating the description of the readonly attribute of the MediaStreamTrack interface, >> * adding at least one track source type (SourceTypeEnum), >> * defining any constrainable properties that are applicable to the media type, >> * updating how the HTMLMediaElement works with a MediaStream containing a track of the new media type, >> * updating MediaDeviceKind, >> * updating the getCapabilities and getUserMedia descriptions, >> * adding the new type to the MediaStreamConstraints dictionary, and >> * describing any new security and/or privacy considerations introduced by the new type. >> >> Additionally, it should include updating >> * the source definition, >> * the list of media stream consumers, >> * the description of the label attribute on the MediaStreamTrack interface, >> * the list of sinks (section 5), and >> * the best practice statements referring to video and audio. >> >> It might also include >> * explaining how the media is expected to be used by elements to which one might assign it (<video> as example for audio and video), and >> * giving examples in sec 4.3.3 of how such a track might become ended. >> >> >> = Defining a new constrainable property = >> >> This will require thinking through and defining how Constraints, Capabilities, and Settings for the property will work. The relevant text in sections 4.3 and 10.3 are the model to use. >> >> Creators of extension specifications are strongly encouraged to notify the Media Capture Task Force of their extension by emailing the list at public-media-capture@w3.org. >> Future versions of this specification and others created by the Media Capture Task Force will take into consideration all extensions they are aware of in an attempt to reduce potential usage conflicts. >> >> ============================================================================= >> >> > >
Received on Tuesday, 8 December 2015 20:00:26 UTC