Re: [Web MIDI] naming and inheritance model

Please, please break the issues and commits apart more - particularly the
issues, but also any large changes should really be separate commits.
 Issues need to represent a single issue (or at most, a related set of
small editorial changes) to be effective.

There are at two pieces of feedback in there that I think should at least
be their own bug (requestMIDIAccess name change, since it's a very breaking
change - aka I need to update a bunch of code at the same time - and the
"SHOULD" in prompting - which is essentially a revert of a change I did a
while ago.)  I don't agree with the security model "SHOULD" change -
reopened bug 17417
<https://www.w3.org/Bugs/Public/show_bug.cgi?id=17417>to represent.

I restructured the open issues a bit to try to separate them out, and
closed the editorial changes issue where you resolved all the changes.



On Thu, Dec 13, 2012 at 8:23 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> 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
>>
>>
>>
>>
>