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

[Bug 20376] Terminology feedback

From: <bugzilla@jessica.w3.org>
Date: Thu, 13 Dec 2012 16:20:32 +0000
To: public-audio@w3.org
Message-ID: <bug-20376-5429-JwwaUqC42j@http.www.w3.org/Bugs/Public/>

--- Comment #3 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
(In reply to comment #2)
> 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()".

Good point, requestMIDIAccess is more accurate. I changed it accordingly. I
think requestMIDI sounds a bit weird, does it request a MIDI spec? Protocol? :D
Anyway: https://dvcs.w3.org/hg/audio/rev/ddd6455eebf6

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

More discussion of the use cases of the "fingerprint" in this bug:

Anyway, I understand where you're coming from with this, but at least exposing
the name and fingerprint are crucial features to have around in order to
support good user experience. The name so that the user can choose what device
to use for what purpose (a lot of the end users of this API will have multiple
MIDI devices they will want to use for different purposes), and the fingerprint
so that the application can maintain the tasks the user assigns to devices
across sessions. I don't really see a good way for this to be completely
handled by the UA without making a really complex API and possibly bad user

Admittedly, the rest of the attributes (version and manufacturer) serve less
purpose, provided that the fingerprint works. But they're not entirely
pointless, after all, MIDI already has sysex and different versions of
different devices from different manufacturers might have different ways of,
for example, uploading new synth patches to the device, so device-specific
programming is a bit difficult to avoid. Especially since I expect that one
prime audience for this API will be manufacturers who want to give users an
easy way to manage the device they bought ("Open your browser and head to this
address to modify your device's settings, no install required!").

> Bikeshed: fingerprint sounds creepy. Please change it to 'id'.

Heh, you're probably right about that.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 13 December 2012 16:20:44 UTC

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