On versioning and extensibility of Media Capture and Streams

There have recently been a couple of discussions related to extending 
and versioning the gUM specification.

One discussion was related to the Last Call comment made by Nigel Megitt 
[1]. After discussing with Nigel the resolution was to make the document 
clearer on how to extend it (recorded in [2]) to cater for e.g. caption 
tracks being defined in an extension.

Another discussion was the one triggered by the Issue that proposed to 
expose camera angles [3] (the discussion is in the Issue comments). This 
discussion touches extensibility, but also versioning of the core spec 
as well as other specs making changes to behavior specified by the core 
specification.

After giving this some thought we’ve concluded that:

- It is clear that basic concepts (such as MediaStream(Track)s, 
constraints/settings/capabilities) described by the gUM spec can be 
useful in other contexts, but that there is often a need to extend them. 
There are already examples of this, e.g. WebRTC, Image Capture and depth 
streams. The discussion on a registry for constraints also falls into 
this category.

- Extending a core spec can in the long run be problematic. The core 
specification can in a new version be changed in a way that makes an 
extension spec invalid for example. Thus, there is a value in the long 
term to fold in extensions into the core specification, and in addition 
it may make more sense in some cases to work on new features as a 
version of the core spec.

Our proposal on how to deal with this is:

- In the core spec in better detail describe how to extend it. Perhaps 
the SW extensibility section [4] can be used as a model

- Develop additions and new functionality as separate documents 
(auxiliary specifications)

- For each new version of the core spec consider merging in 
functionality currently in auxiliary specifications.

It has been proposed to develop the core specification in parallel 
tracks (using separate branches in github), e.g. “Rec-track” and 
“Nightly”. We believe that is a model that should be used with caution 
as we fear that as soon as people start working on the “Nightly” version 
the momentum to finalize the “Rec-track” will be lost. We think the 
model adopted in the WebRTC WG, where the work on a next version can’t 
start until the current version reaches CR, is better.

Feedback wanted!

Stefan for the chairs

[1] 
https://www.w3.org/2006/02/lc-comments-tracker/47318/WD-mediacapture-streams-20150414/3013
[2] https://github.com/w3c/mediacapture-main/issues/244
[3] https://github.com/w3c/mediacapture-main/issues/236
[4] 
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/#extensibility

Received on Wednesday, 7 October 2015 06:28:36 UTC