W3C home > Mailing lists > Public > www-dom@w3.org > April to June 2013

Re: Seeking guidance on MIDIMessageEvent design, was Fw: [MIDI] bump: Issue 1: MIDIEvent lacking constructor

From: Anne van Kesteren <annevk@annevk.nl>
Date: Tue, 16 Apr 2013 16:43:40 +0100
Message-ID: <CADnb78i790TZ+drQGMQ1q5pmbMKJgJ69K_C5USH4AO9VMa8f4A@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: "www-dom@w3.org" <www-dom@w3.org>, Chris Wilson <cwilso@google.com>
On Sun, Apr 14, 2013 at 9:50 PM, Marcos Caceres <w3c@marcosc.com> wrote:
> Any additional constructive feedback on the design of the API would be greatly appreciated.
> [1] http://webaudio.github.io/web-midi-api/

It seems requestMIDIAccess should use a future (I know this tune is
getting old quickly, but it's true!)

You need to state how MIDIPort.id is scoped (prolly to origin, no?)
and you should state that it should not be the same across origins. We
don't want to make it easy to track users using these new identifiers.
Furthermore, once the user clears cookies these MIDIPort.id thingies
need to be regenerated too. (I gave similar feedback to the WebRTC

Is there a reason to expose manufacturer, name, and version? It would
be helpful to point those out, but maybe starting without them would
be even better.

I'm not entirely sure, but you might have to overload sequence<octet>
with ArrayBuffer as using the former also for the latter might have
observable side effects while you actually would want to optimize that
case. (Not a 100% sure though.)

I suggest you put this by public-script-coord@w3.org to see if anyone
there has review comments. (If you do that please do it as a fresh
email that introduces the API.)

Received on Tuesday, 16 April 2013 15:44:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC