- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Wed, 21 Mar 2012 20:22:48 +0100
- To: Dominique Hazael-Massieux <dom@w3.org>
- CC: public-webrtc@w3.org
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