- From: Anant Narayanan <anant@mozilla.com>
- Date: Mon, 12 Mar 2012 06:44:43 -0700
- 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! Thanks, -Anant
Received on Monday, 12 March 2012 13:45:17 UTC