Re: PROPOSAL: Use events instead of callbacks

Q1: Could someone point me at a good description of how events work, and 
where their definition lives?

Q2: This style would create an object that represents "the head of the 
MediaStream". Would it be logical to move some of the manipulation 
functions we've been thinking of for MediaStreams onto that object, if 
this is adopted?
I'm thinking in particular of the API for turning on/off echo 
cancellation, which should be conceptually as close to the microphone as 
possible.

Q3: If we adopted this behaviour, would the function

function oldStyleGetUserMedia(opts, success, fail) {
    var media = navigator.getUserMedia(opts);
    media.addEventListener('onsuccess', function(event e) { 
success(e.stream) }
    ... same for failure ..
}

constitute a drop-in replacement for "old-style" code, or are there 
subtleties here that need exploring?

Q4: could we use a different name for the new function?

Not speaking at all to the "is this hard for existing implementations" 
argument......

On 03/06/2012 08:47 PM, Travis Leithead wrote:
> If you take this approach, then you'll want to use the DOMError instead...
>
>> 	NavigatorUserMedia.error ->  A NavigatorUserMediaError object assigned
>> (null otherwise).
> NavigatorUserMedia.error ->  A DOMError object assigned (null otherwise)
>
> :)
>
> I understand that there are some general concerns with this design due to early existing implementations of the callback approach. Specifically, Rich and someone from Google should reply with their thoughts.
>
> -Travis
>
>> -----Original Message-----
>> From: Anant Narayanan [mailto:anant@mozilla.com]
>> Sent: Tuesday, March 06, 2012 11:38 AM
>> To: public-media-capture@w3.org
>> Subject: PROPOSAL: Use events instead of callbacks
>>
>> What
>> --
>> Change the function signature of navigator.getUserMedia to return a
>> 'NavigatorUserMedia' object that extends 'EventTarget' (fully specified in
>> http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget) and
>> eliminate the use of success and error callbacks:
>>
>> 	var media = navigator.getUserMedia({'video':true});
>> 	media.addEventListener('onsuccess', function(Event e) {
>> e.target.stream }, false);
>> 	media.addEventListener('onerror', function(Event e) { e.target.error
>> }, false);
>>
>> Why
>> --
>> Events are preferred to callbacks in almost all WebAPIs in wide use today,
>> examples include XHR and IndexedDB. Events are more flexible than callbacks
>> as they allow multiple listeners, chaining, and bubbling; none of which are
>> supported by a single callback (as currently specified in the
>> specification). Some applications will not need the flexibility provided by
>> Events, but it is trivial to emulate a single callback system built on top
>> of events and is also a common idiom for web APIs:
>>
>> 	var media = navigator.getUserMedia({'audio':true});
>> 	media.onsuccess = function(e) { e.target.stream; };
>>
>> How
>> --
>> The function getUserMedia can be changed to return an object (the proposal
>> calls it a 'NavigatorUserMedia' object) that extends 'EventTarget'. Event
>> listeners can be added and removed using the standard event target methods.
>> The 'Event' object passed to the onsuccess and onerror event listeners will
>> have Event.target set to the 'UserMedia' object, which as the following two
>> properties:
>>
>> 	NavigatorUserMedia.stream ->  A MediaStream object assigned (null
>> otherwise).
>> 	NavigatorUserMedia.error ->  A NavigatorUserMediaError object assigned
>> (null otherwise).
>>
>> I look forward to your feedback!
>>
>> Regards,
>> -Anant
>>
>>
>
>
>

Received on Tuesday, 6 March 2012 20:44:04 UTC