Re: WebMIDI API feedback

On Fri, Apr 19, 2013 at 8:31 AM, Alex Russell <slightlyoff@google.com>wrote:

> requestMidiAccess can (should?) be re-worked to vend a Future. A cleaned
> up interface for it might be:
>

I'm not yet convinced this is a should vs. a can, but we'll talk more.  I
filed this as an Issue: https://github.com/WebAudio/web-midi-api/issues/49.


> The naming of "onmessage" and "send" also seem odd. We have "onmessage"
> for receivers of postMessage()-sent data. I'm not suggesting overloading
> "postMessage", but perhaps "ondata" might be less confusing to developers
> who see/use both?
>

Well, crap.  Actually, it currently WOULD be an overload of postMessage's
message, which isn't good.  I don't particularly like "ondata" either, and
think it should probably be explicit that it's a MIDI message in order to
not claim namespace.  "onmidi"?  Issue filed:
https://github.com/WebAudio/web-midi-api/issues/50.

In 6.2, I see methods called "getInputs", and "getOutputs" which don't take
> any parameters. Is there a reason these aren't getters, which would allow
> you to drop the "get" prefix and avoid the camel-casing entirely?
>

Active issue: https://github.com/WebAudio/web-midi-api/issues/2.  This
design has changed over time, think it needs to change one more time.


> There don't appear to be constructors for your Event subtypes. This is
> clearly a bug. All new interfaces for which you can be vended concrete
> instances should come with constructors defined.
>

Active issue: https://github.com/WebAudio/web-midi-api/issues/1. I just
need a few spare cycles to write them up.


> Lastly, are y'all looking at the ES6 binary data proposal? Just want to
> make sure we're not doing anything there that's going to make life hard for
> your API assumptions:
> http://wiki.ecmascript.org/doku.php?id=harmony:binary_data
>

I've seen it.  I don't think it causes any changes or difficulty.

-Chris