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

[Web MIDI] naming and inheritance model

From: Marcos Caceres <w3c@marcosc.com>
Date: Thu, 13 Dec 2012 15:16:48 +0000
To: public-audio@w3.org
Message-ID: <29D9C733003D4EC785E3BB56CA21597D@marcosc.com>
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 15:17:18 UTC

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