- From: Brian LeRoux <b@brian.io>
- Date: Wed, 30 Nov 2011 06:26:21 -0800
- To: JOSE MANUEL CANTERA FONSECA <jmcf@tid.es>
- Cc: Robin Berjon <robin@berjon.com>, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Agree w/ Robin that the Stream object needs a slightly more robust abstraction, and also agree the inspiration should come from NodeJS since there is solid prior art there. That said, Streams have a few more characteristics that might make them better candidates for addEventListener. First, streams docs on NodeJS: http://nodejs.org/docs/v0.4.7/api/streams.html Looking there, we could imagine an interface that is more of the spirit: navigator.getUserMedia('video').addEventListener("end", function() { console.log('camera has been turned off') }, false) But what if we have multiple cameras? Front and back are common enough now. navigator.cameras[0].addEventListener("end", function() { console.log('camera has been turned off') }, false) If we are in the business of considering our API design now then it might be good to note that: - W3C style addEventListener is verbose - passing a string to id the event is error prone since it hides misspelling bugs at write AND run time - the final param of addEventListener (capture) is rarely, if ever, used, and besides a default false behaviour is a common cowpath - navigator is getting rather full of stuff; namespaces are a honking good idea --- we should do more of that! - exception events end up creating nasty out of context flow control code that considered we could look at something like this: navigator.media.cameras[0].end(function(err, data) { if (err) { console.log('uh oh') return; } console.log('camera off') }) (and have analogs for: start, data, close) On Wed, Nov 30, 2011 at 4:00 AM, JOSE MANUEL CANTERA FONSECA <jmcf@tid.es> wrote: > +1 to drop the success / error callback using one of the mechanisms > proposed by Robin
Received on Wednesday, 30 November 2011 14:26:55 UTC