W3C home > Mailing lists > Public > public-webrtc@w3.org > March 2012

Schedule & spec organizations; giving priority to getUserMedia

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 20 Mar 2012 10:56:09 +0100
Message-ID: <1332237369.8723.112.camel@altostratustier>
To: public-webrtc@w3.org
Hi,

As you may know, the W3C Patent Policy only protects specs once they
have reached the final stage of the standardization process
(Recommendation status).

It implies that to protect as well as possible implementers and users of
the technologies we develop, we need to bring our specs to
Recommendation status as fast as possible (without compromising their
quality obviously).

There are two main traditional bottlenecks in the Rec track:
* Last Call, where we get most of the comments from other groups and
need to respond formally to all of them 
* Candidate Recommendation, where we need to prove that each feature of
the given spec is implemented interoperably, which itself more or less
requires a test suite

It seems to me that the best way to go fast through the Rec track
process is thus to organize our specs around small set of features
(which reduces the number of comments we get at LC) that we know will
get implemented roughly simultaneously (so that one feature doesn't
delay progress for the other features).

This approach also needs to take into account dependencies between
features; but rather than looking it at a formal level, I think we
should look at dependency in the way implementations do: i.e. there is
only a dependency if most implementors aren't going to implement a
feature without another one.

To take a concrete example, it's clear that there is a dependency
between getUserMedia and MediaStream (since nobody will implement one
without the other).
On the other hand, there is likely no such a dependency between the
Constraints API and getUserMedia, even though formally speaking (the
current proposal for) the Constraint API modifies the getUserMedia
function. But since there are already implementations of getUserMedia
out there (Opera, Chrome, IE) that don't even try to do constraints,
there is no dependency with my definition. It's good that we have an
early proposal for constraints since it means we can future-proof
getUserMedia, but we probably don't need a much more advanced proposal
to make progress on getUserMedia.

Using that definition, I think our dependency diagram looks like:
MediaStream — getUserMedia — PeerConnection — DataChannel
                           \                \
                             Constraint API — Capabilities API

(there are probably more components to it; my understanding might also
be wrong; but let's assume it is correct as a starting point)

If that is correct, I think the Working Group should focus most of its
efforts toward pushing the combination of MediaStream + getUserMedia to
Recommendation; it's a fairly well-defined scope, and has already
prototypes — we could go to Rec very quickly with dedicated efforts
toward that.

I would assume the next priority would be PeerConnection, most likely
bundled with DataChannel from what I've heard so far.

If we agree on this, I think we should direct most of our efforts toward
getUserMedia first, and work on PeerConnection in the time when
getUserMedia doesn't need attention.

This could mean in practice:
* give more time to getUserMedia in calls/F2F (although given that gUM
is a joint work with DAP this might not be particularly practical in
most cases)
* ask people to give priority to action items relating to getUserMedia
* ask editors to focus on getUserMedia
etc.

Some of the things that I think we should do in such an approach
include:
* identify which features of MediaStream + getUserMedia will need review
from e.g. WAI, I18N, etc (can't see many off the top of my head, but
probably worth verifying)
* look at the set up for test suite for getUserMedia now (even if we
don't necessarily build tests quite yet)

I'm interested in feedback — thanks for reading so far :)

Dom
Received on Tuesday, 20 March 2012 09:56:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 20 March 2012 09:56:38 GMT