- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 26 Jun 2012 15:23:46 +0200
- To: public-audio@w3.org
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 * prefixing all properties in MIDIDevice with "device" seems a bit redundant * 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) * 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 * if getInput/getOutput can also take a string parameter (for the fingerprint), the type of the parameter should be (MIDIDevice or DOMString) * Uint8Array is not defined in WebIDL; I guess it comes from WebGL, but then that spec should probably be referred * NavigatorMIDIAccessError should probably be removed in favor of a DOMError with type SECURITY_ERROR (?) * MIDIMessage should probably be a dictionary rather than an interface 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). 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. Dom 1. https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html#event-midiinputdevice-midimessage
Received on Tuesday, 26 June 2012 13:24:15 UTC