Re: [Web MIDI] naming and inheritance model

On Thu, Dec 13, 2012 at 9:29 PM, Chris Wilson <cwilso@google.com> wrote:

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

You're right, sorry about that!  :)


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

Thanks!

- Jussi


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