Re: Defining the split on WebRTC deliverables

On 12/07/2011 01:38 PM, Rich Tibbett wrote:
> We've briefly touched on this before [1] but I'd like for us to 
> consider pursuing a clearer split between the Local Media API and the 
> WebRTC API considering the intended use cases of each deliverable.
>
> As a developer, if my intention is to obtain and work with the user's 
> webcam and microphone on the client-side without any streaming, I 
> should be able to find that documentation separate from anything like 
> P2P sharing of that data.
>
> It happens that we're in the process of building a web 'toolchain' 
> comprised of a number of discrete interfaces that can act 
> independently from each other. This is similar to some web toolchain 
> concepts in use today: the same way that <video> data can be piped to 
> <canvas> and piped back out to display in an <image> element while 
> each of those elements can also act independently of each other.
>
> It also so happens that both of these subjects require a significant 
> amount of specification work, that implementation of these features 
> may be on different timescales and that, therefore, they should be 
> treated as separate deliverables that share a common timeline, with 
> their own separate test suites to which implementations can then claim 
> conformance without failing >50% of tests which are non-applicable to 
> an implementation of one or the other.
>
> In short: MediaStream implementation or testing or usage != 
> PeerConnection implementation or testing or usage.
>
> The proposal is to move the 'Stream API' section from the WebRTC spec 
> [2] to the current getUserMedia specification [3].
>
> The WebRTC specification should define 'Peer-to-peer connections' in 
> all their complexity without having to also account for generic 
> MediaStream definitions. If there are any additional Peer-to-peer 
> related operations required on MediaStream objects, then the WebRTC 
> specification should extend the MediaStream object as required and 
> include that functionality specifically in the WebRTC spec.
>
> As a subsequent, future task, the Media Capture Task Force may also 
> evaluate how we could integrate the Streams API proposal from 
> Microsoft [4] to enable additional local-media capture use cases. 
> Streaming from all of this captured data is an additional tool in the 
> web toolchain and we should try to split our development work as such.
>
> Would there be any issues with moving 'Section 3: Stream API' from the 
> WebRTC API spec to the Media Capture API spec? *
Yes.

The discussion so far has indicated that the nature of the beasts within 
a MediaStream is critically tied to their on-net representation as 
mediated by a PeerConnection. This close connection is mirrored in 
current implementation strategies for MediaStream.

I am not at all happy at the thought of potentially revectoring 
MediaStream to be chiefly a mechanism for local applications.

Given the time it took me to get my head out of the "it's a stream of 
bytes" fallacy, I wouldn't like to encourage others to be caught in the 
same trap.

>
> FWIW, if the DataStream interface [5] has any client-side usage 
> without PeerConnection then it too should be treated as a separate 
> deliverable IMO.
>
> We should also try early on to converge [2], [4] and [5]. Anyone want 
> to get the ball rolling on that in a separate thread?

I am not so sure we should converge all of those. Some of them may need 
to go off to die on their own, others may turn out to be subclasses of 
some abstract superclass somewhere.

A MediaStream is not a stream of bytes. At some points it can be 
represented as one; at other poitns it may create one. But it isn't one.

>
> br/ Rich
>
> * I'm proposing that we rename of the 'getusermedia' document to 
> 'Media Capture API' unless there are any objections.
>
> [1] 
> http://lists.w3.org/Archives/Public/public-media-capture/2011Nov/0006.html
>
> [2] http://dev.w3.org/2011/webrtc/editor/webrtc.html#stream-api
>
> [3] http://dev.w3.org/2011/webrtc/editor/getusermedia.html
>
> [4] http://dvcs.w3.org/hg/webapps/raw-file/tip/StreamAPI/Overview.htm
>
> [5] 
> https://docs.google.com/document/pub?id=16csYCaHxIYP83DzCZJL7relQm2QNxT-qkay4-jLxoKA&pli=1
>
>
>

Received on Friday, 9 December 2011 22:06:04 UTC