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

Thanks Anne - I'll run the API by public-script-coord.

I'm a bit nervous about using futures rather than a simple callback, but
I'll have a try refactoring using futures and see how it flows - I'll try
it out before sending to script-coord.

Excellent point about domain tracking and ids.  Filed:
https://github.com/WebAudio/web-midi-api/issues/48.

Manufacturer, name and version are standard in other MIDI APIs - we could
drop version without much problem, but the user needs to be able to
identify the devices (e.g. to provide a dropdown list of available devices).

-Chris


On Tue, Apr 16, 2013 at 8:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> 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
> guys.)
>
> 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.)
>
>
> --
> http://annevankesteren.nl/
>