Re: CHANGE: Use a JS Object as an argument to getUserMedia

FWIW,

my thinking was that the browser would offer remember the user selection 
for getUserMedia per origin. I think this is the way it is usually done 
for the Geolocation API (<http://dev.w3.org/geo/api/spec-source.html>).

There can be flavors of this, such as "remember for a certain period of 
time", or that the selection is remembered but when returning to the 
site you would have to click some lens cover icon in the chrome, or 
something else, but I think popping a user dialog every time you use 
getUserMedia would not be OK from a usability point of view. And of 
course there must be indications, and revocation buttons, in the chrome.

This way a trusted app would have access to audio and video per default; 
but of course the app can be designed to start sessions with audio only 
anyway (requiring the user to take action to add video).

Stefan

On 10/07/2011 09:33 AM, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
>
>
> On Thu, Oct 6, 2011 at 21:55, Anant Narayanan <anant@mozilla.com
> <mailto:anant@mozilla.com>> wrote:
>
>     Hi Tommy, Adam,
>
>
>     On 10/5/2011 6:51 AM, Adam Bergkvist wrote:
>
>         I agree with Tommy. Right now, once you have a MediaStream you
>         can start
>         using it. If getUserMedia returns a stream directly, it would
>         have to be
>         empty (no tracks), and tracks would have to be added later. I
>         think it
>         would simplify things (e.g. MediaStream playback and sending with
>         PeerConnection) if a MediaStream is immutable with regards to
>         its track
>         list.
>
>
>     I think it is unrealistic to assume that MediaStreams are immutable.
>     Web developers are already very familiar with the concept that an
>     XMLHttpRequest is a living object and that changes will happen to it
>     continuously which they must monitor and respond to.
>
>     A MediaStream is no different, and there are multiple circumstances
>     under which a stream may change, some of which are:
>
>     - Network disruption
>     - Physical disconnection of webcam/microphone
>     - Software mute at OS level of microphone
>
>     Since the web application must be able to respond to any of these
>     (and other) changes to the MediaStream, we will most likely
>     standardize on several DOM events on the MediaStream object anyway.
>     Taking it one step further and adding an event for track addition
>     and removal feels very "webby" to me :)
>
>     That being said, I'd like to hear about what you think the
>     advantages of having an immutable track list are; and if you think
>     user-agents are able to guarantee that?
>
>
> I'm all for adding more events to PeerConnection, *MediaStream and
> MediaStreamTrack*. Right now everything is solved by streaming black
> video and/or silence when foobar happens.
>
>
>
>         On 2011-10-05 08:59, Tommy Widenflycht (ᛏᚮᛘᛘᚤ) wrote:
>
>             Yeah, I understood that during the office hour call. Dunno, your
>             suggestion seems less elegant and clear but that might just
>             be because
>             I am quite new to the JS world. Can you list some use cases
>             where your
>             suggestion will really make a difference?
>
>
>     One of my primary goals is to make the getUserMedia API as close to
>     other Web APIs as possible. In the simplest case of the web
>     developer who wants both a video and audio stream, the call would
>     look like:
>
>     var stream = navigator.getUserMedia();
>     stream.addEventListener("__readyState", streamIsReady);
>     function streamIsReady() { ... // note that errors can be handled
>     here too, if we choose to define readyState to be broad }
>
>     In the current spec, this looks like:
>
>     var stream = navigator.getUserMedia("audio,__video", streamIsReady,
>     streamError);
>     function streamIsReady() { ... }
>     function streamError() { ... }
>
>
> Sorry, but you are wrong about how the current spec looks like;
> getUserMedia is a void function. The MediaStream object is delivered
> only to the streamReady callback if the user granted access and the
> required hardware was found. I like this way a lot.
>
>     Two reasons why I prefer the former over the latter:
>
>     - Events > Callbacks. Events propagate, can be chained (ala jQuery),
>     and there can be multiple listeners for the same event which is
>     useful in some cases. That is not true of explicit callbacks.
>
>     - An event like "readyState" is broad enough (just like the event of
>     the same name in XHR) to cover many cases, so in the typical case
>     the developer has to attach only one event listener. Of course we
>     can choose to add other events to provide even more flexibility, and
>     the more sophisticated web-apps will have multiple event listeners
>     (which is fine IMO).
>
>     I feel that since developers will be attaching event listeners to a
>     MediaStream anyway, asking them to do right after they get one from
>     getUserMedia is not necessarily a bad thing. This is a paradigm we
>     should try and encourage.
>
>     I'm still open to arguments and can be convinced otherwise! But this
>     makes it feel very close to some of the other async Web APIs out
>     there and feels intuitive as a JS developer to me :)
>
>     Thanks,
>     -Anant
>
>
>
>
> --
> Tommy Widenflycht, Senior Software Engineer
> Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
> Org. nr. 556656-6880
> And yes, I have to include the above in every outgoing email according
> to EU law.

Received on Friday, 7 October 2011 12:28:02 UTC