Re: First draft available

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