Re: WebMIDI API feedback

On Fri, Apr 19, 2013 at 8:31 AM, Alex Russell <>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:

> 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:

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:  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: 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:

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


Received on Saturday, 20 April 2013 13:18:32 UTC