W3C home > Mailing lists > Public > public-audio@w3.org > October to December 2012

Re: [Web MIDI] naming and inheritance model

From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Date: Thu, 13 Dec 2012 18:23:46 +0200
Message-ID: <CAJhzemXTcBzV7JFW3OxqcUtDK6a34AfEE_BK7mEVoHG+-0dBUw@mail.gmail.com>
To: Marcos Caceres <w3c@marcosc.com>
Cc: public-audio@w3.org
Hey Marcos!

Thanks for your valuable feedback!

There are two separate bugs [1][2] for your feedback now, and I have just
made some commits addressing a few of your concerns already. :)

Cheers,
Jussi

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20364
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20376

On Thu, Dec 13, 2012 at 5:16 PM, Marcos Caceres <w3c@marcosc.com> wrote:

> Some more rapid fire feedback :)
>
> Bikeshed: getMIDIAccess is a misnomer. The developer is not guaranteed
> access to the MIDI interface, so it's a "request". Hence, this method
> should be renamed to "requestMIDIAccess()" or just "requestMIDI()".
>
> The following is also incorrect:
>     [TreatNonCallableAsNull] attribute callback? onmessage;
>
>
> Please change it to:
>  attribute EventHandler onmessage;
>
> It would be better if you could fold everything into MIDIPort and get rid
> of MIDIOutput and MIDIInput? you already have the port type, and you can
> just say that sending() does nothing when a port is not outputting.
>
> If you don't agree, then I think MIDIInput and MIDIOutput need to inherit
> from MIDIPort (not implement the interface). Implementing the interface
> makes a huge mess when actually implementing, as the stuff from MIDIPort
> has to be copied over from MIDIPort.
>
> So, worst case, please change the spec to match the following pattern:
>
> interface MIDIOutput : MIDIPort {
> }
> interface MIDIInput : MIDIPort {
> }
> MIDIPort : EventTarget{
> }
>
>
>
> However, I strongly urge you to do away with MIDIInput and MIDIOutput.
> They are redundant, IMHO.
>
> I have a strong concerns about exposing the manufacturer and fingerprint
> attributes. Adding the manufacturer encourages device specific programming,
> which is bad (it also serves as a strong vector for fingerprinting).
>
> I understand the use case for the fingerprint attribute, but I think that
> use case should be handled by the UA and not exposed to the developer. I'm
> not sure what the right solution is here either, but what is currently
> there does not feel right.
>
> Bikeshed: fingerprint sounds creepy. Please change it to 'id'.
>
> --
> Marcos Caceres
>
>
>
>
Received on Thursday, 13 December 2012 16:24:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:04 UTC