Re: Schedule & spec organizations; giving priority to getUserMedia

Dom,

personal reaction only....

when the project was created, I saw the challenge as being communication 
between browsers, and real time media communication between browsers and 
other things.
The idea of getUserMedia as a separable feature was (to my view) a 
relative latecomer.

At the moment, it seems that some implementors (Opera, IE) are rolling 
out getUserMedia in advance of, and sometimes even a commitment to, 
inter-browser real time communication.
So it seems the landscape has changed, and we may need to change 
priorities to align.

I disagree with some of your prioritizations:

- for the final getUserMedia API, the constraints API must be specified, 
because constraints are part of the getUserMedia API, and cannot be 
added afterwards.

- PeerConnection depends only indirectly on getUserMedia - the common 
denominator is MediaStream. But until we have a means of generating 
mediastreams from other sources than getUserMedia, all practical 
applications will be dependent on having getUserMedia.

- The recorder interface is another example of a terminal point in the 
graph: Nothing depends on it, so it can safely be delayed without 
delaying other things

- Specific constraints definitions can be delayed by almost any amount 
without much impact.

So my dependency graph goes at least in part like this:

           /--- Recorder interface
          /
MediaStream <------------------- GetUserMedia
                                 |
Constraints interface <---------+ PeerConnection (media) <---------------\
                                                                           \
                        Data API <-----------------------------------  
PeerConnection (full)


Luckily, a number of things have drafts now, including the constraints 
interface.
And we do have implementations of several of the proposed pieces.


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 Wednesday, 21 March 2012 19:23:23 UTC