Re: Comments on draft MIDI API

Hey Dom!

Thanks for taking the time reviewing the spec! Answers inline...

On Tue, Jun 26, 2012 at 4:23 PM, Dominique Hazael-Massieux <dom@w3.org>wrote:

> Hi,
>
> As I'm glancing through the editors of the proposed MIDI API [1], a few
> comments on problems I've spotted:
>
> * sequence<> shouldn't be used as attributes (but instead arrays should
> be used) in MIDIEvent
>

I'm not sure I understand the difference, I thought sequence will be
implemented as an array?


> * prefixing all properties in MIDIDevice with "device" seems a bit
> redundant
>

Yes, you may be right, I was thinking to be too future-proof to avoid
naming clashes.


> * MIDIDevice should have a type (or deviceType) attribute instead of
> defining it in MIDIInputDevice and MIDIOutputDevice; that type attribute
> should be defined with an enum with values "INPUT" and "OUTPUT" (not
> sure why it needs uppercase though)
>

Good point, I'll probably change this.


> * I'm surprised that the enumerate*/get* methods on MIDIAccess seem seem
> to synchronous; I would expect that these operations would require
> enough time that they shouldn't block the main thread; also, it doesn't
> look like the API allows to deal with plugging/unplugging MIDI devices
>

I don't see how these operations could possibly be long enough to block the
main thread for long enough to warrant for an asynchronous behaviour, it's
highly unusual for an operation like this to be even one millisecond long.

And the API does allow for (un)plugging. [1]


> * if getInput/getOutput can also take a string parameter (for the
> fingerprint), the type of the parameter should be (MIDIDevice or
> DOMString)
>

Will fix, I'm fairly unfamiliar with WebIDL and didn't know this was
possible.


> * Uint8Array is not defined in WebIDL; I guess it comes from WebGL, but
> then that spec should probably be referred
>

The WebGL Typed Arrays spec is already referred to. [2]


> * NavigatorMIDIAccessError should probably be removed in favor of a
> DOMError with type SECURITY_ERROR (?)
>

Good point, will probably change unless there's something against this.


> * MIDIMessage should probably be a dictionary rather than an interface
>

Why & how?


> At a higher level, it seems like this API has a very strong
> fingerprinting risk (due to enumeration of devices, esp. as they
> themselves have a fingerprint property).
>

Indeed, hence the security model of asking user permission via
getMIDIAccess.


> Also, I idly wonder if getting input from MIDI devices shouldn't be done
> via getUserMedia rather than through its own API; I'm not really sure
> how that would work, but I thought I would still share the question.
>

This has been discussed a bit already, and the original security model I
proposed used getUserMedia, but the concensus (for now) is that MIDI
doesn't make that much sense as streams (by default). Instead there are
plans to integrate more with the MediaStreams API in a later version, for
example giving all MIDI input devices a .stream attribute, but for now
there isn't much gained value. We'll revisit this when the MediaStreams API
is more widely adopted and we can evaluate benefits such as P2P MIDI
communication, cross-context transfer of MIDI events etc.


>
> Dom
>
> 1.
>
> https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html#event-midiinputdevice-midimessage
>
>
Cheers,
Jussi

[1]
https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html#idl-def-MIDIDevice
[2]
https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html#terminology