Re: PROPOSAL: Use events instead of callbacks

I think Rich already answered most of your question, just a few more 
comments:

On 3/6/2012 12:43 PM, Harald Alvestrand wrote:
> 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?

Yes, I'm in favor of adding more such listeners to the UserMedia object 
which represents a state far earlier than when a MediaStream can be 
"live". That said, I am not opposed to having convenience methods in the 
MediaStream object; but if having both is confusing, I prefer the former.

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

No, this works. However, I don't see why that is easier than:

var media = navigator.getUserMedia(opts);
media.onsuccess = success;
media.onerror = fail;

The events spec allows for this, if you don't need more than one 
listener you can directly attach your callback to the 
'onsuccess'/'onerror' properties.

>
> Q4: could we use a different name for the new function?
>
> Not speaking at all to the "is this hard for existing implementations"
> argument......

I'm not opposed to a new name - getUserMedia always sounded a little 
clunky to me :) However, I do feel like having two functions specified 
in our draft is unnecessary - there is no precedent for having two 
different functions under the navigator namespace that differ only in 
events/callbacks.

-Anant

Received on Monday, 12 March 2012 13:35:51 UTC