W3C home > Mailing lists > Public > public-media-capture@w3.org > March 2012

Re: PROPOSAL: Use events instead of callbacks

From: Anant Narayanan <anant@mozilla.com>
Date: Mon, 12 Mar 2012 06:44:43 -0700
Message-ID: <4F5DFDCB.5030003@mozilla.com>
To: "public-media-capture@w3.org" <public-media-capture@w3.org>
On 3/7/2012 4:44 AM, Rich Tibbett wrote:
> I'm not in favor of changing from the callbacks approach but in a
> *worst-case scenario*, we could manage a change such as this as long as
> we choose a different name for the new function.
> The onus must still be to explain why we would need this change though.
> I've been on the events vs callbacks merry go round more than a couple
> of times before and the differences seem to mostly boil down to personal
> and ideological preferences rather than real technical flaws or
> deficiencies of either approach.

You are right, this is mostly an ideological preference. At Mozilla, 
we're trying to propagate one approach (events) to all web standards we 
are working on (as there seem to be a lot of them popping up these 
days!), because we think they have a (very tiny) edge over callbacks.

> Right. We released navigator.getUserMedia in Opera Mobile 12 in to the
> hands of multi-millions of users so this is not a trivial argument at all.
> It's important to explain what benefits we obtain against the callbacks
> approach. Perhaps you could provide specific use cases where the
> callback approach is failing to date?

Having slept on it a bit, I think it all boils down to being able to 
have multiple listeners in an easy manner. You could for example, have 
different portions of your page (or even some web workers) that need to 
be notified as soon as MediaStream is available. This is not impossible 
with the callback approach but it leaves the implementation up to the 
web developer, which seems unnecessary especially because we already 
have very thorough event specification.

As Adam correctly points out subsequently in the thread, chaining and 
bubbling don't really make sense for getUserMedia. However, they do make 
sense for a MediaStream (which could be attached to a <video> or 
<canvas>, and may want to bubble events back into the parent). Thus, if 
we add events to MediaStream, I think there's a good case for having 
them be real events. At that point, it's only a matter of consistency 
for having getUserMedia behave in a similar manner.

All that being said, I do not feel strongly enough about this issue to 
warrant specifying a new function. What does worry me though, is having 
an implementation of getUserMedia already out there in an unprefixed 
form. Leaving this particular issue aside, I hope that it does not 
affect making changes to the spec where it is deemed necessary!

Received on Monday, 12 March 2012 13:45:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:24:35 UTC