Re: Combined synchronous gUM proposal proposal

I'm starting to like this version more and more. :) At first I thought 
it had too verbose syntax.

On 2012-12-06 18:36, Martin Thomson wrote:
> Option 3 required that users create MediaStreamTrack objects of
> specific types using the new operator.
>
>    var audio = new AudioStreamTrack(...);
>    var video = new VideoStreamTrack(...);
>    var stream = new MediaStream([audio, video]);

At this point I guess the tracks would:
- be muted (in our current API)
- not have an associated source (in Travis settings v5)

>    navigator.getUserMedia(stream, successCb, errorCb);

This is pretty powerful. Constraints can be applied with precision (at 
track level) and the number of tracks doesn't have to be limited to two 
as in the "normal" case (assuming the selector UI can handle more than 
two tracks).

> EKR wants to ensure that users who aren't constrained by the sorts of
> constraints that lead to the need for this synchronous option aren't
> forced to go through the extra steps.
>
>    navigator.getUserMedia({audio:true, video:true}, successCb, errorCb);
>
> This is trivially possible with an overload/union type:
>
>    partial interface navigator {
>      void getUserMedia(GetUserMediaInput shape,
> GetUserMediaSuccessCallback success, GetUserMediaFailureCallback
> failure);
>    }
>    typedef (MediaStreamConstraints or MediaStream) GetUserMediaInput;
>    callback GetUserMediaSuccessCallback = void (MediaStream stream);
>    callback GetUserMediaFailureCallback = void (GetUserMediaError error);
>    interface GetUserMediaError : Error {
>      // not sure what goes here in addition to the other stuff
>    }
>
> The success callback includes the same stream you provided as input,
> or a newly created one that is based on your input constraints.  Same
> API.
>
> Constraints are attached to tracks in the /higher effort/ API using
> MediaTrackConstraints, which is nicer and enables things like getting
> multiple cameras.  MediaStreamConstraints becomes the low-road option
> for getUserMedia.
>
> I briefly considered having getUserMedia return the MediaStream that
> it creates, which would enable the creation of a placeholder using the
> existing API, which would get us option 1 as well, but that seemed a
> little over the top.

I think we should avoid having both a return value and callbacks.

/Adam

Received on Friday, 7 December 2012 08:43:21 UTC