Re: Schedule & spec organizations; giving priority to getUserMedia

Dom,

thanks for writing this up (and sorry for top-posting). I think it makes 
an awful lot of sense to push things that are not implemented, and not 
needed from day one, to later updates.

However, I am not sure that separating out PeerConnection from the list 
of "do early things" makes sense. There are already implementations out 
there. And it may prove difficult to make a good design of MediaStream 
without taking PeerConnection aspects into account - you risk having to 
re-define the MediaStream API later.

Just off the top of my head, things that to me seem not yet well 
specified, or not implemented (in terms of API at least), and that 
perhaps could be excluded from a very first release includes:

- Constriants/capabilities
- DTMF
- MediaRecorder (there was even a bug filed to remove it the other day)

Would be interesting to hear what others think.

Stefan

On 03/20/2012 10:56 AM, Dominique Hazael-Massieux wrote:
> 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 15:27:45 UTC