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