Re: Schedule & spec organizations; giving priority to getUserMedia

Le mardi 20 mars 2012 à 16:27 +0100, Stefan Hakansson LK a écrit :
> However, I am not sure that separating out PeerConnection from the list 
> of "do early things" makes sense. There are already implementations out 
> there.

My reasoning for pushing it to later (but I would agree that it would be
only slightly later) is that we already know that we'll have
implementations of getUserMedia that don't have PeerConnection (since
Opera released getUserMedia, and the IE Media Capture prototype [1] only
focuses on gUM as well).

>  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.

I think what we need is sufficient confidence that the what getUserMedia
needs from the MediaStream API doesn't interfere with what
PeerConnection will need.

But defining a partial interface for MediaStream that completes what is
defined in getUserMedia seems like a good way to deal with updating it
for PeerConnection.

Now, I haven't looked closely at how confidently we can split
MediaStream with that approach; but again, given that implementations
are already starting to do that split, I think it's fair to expect we
can get there, and even that we need to get there soon if we want to
avoid interoperability problems down the line.

> 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)


I think it would be a useful exercise to identify the components that we
envision for our work, and how they depend on each other (but again, in
terms of implementation dependence, not spec)



Received on Tuesday, 20 March 2012 15:45:12 UTC