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

[Bug 20505] merge getInput, getOutput -> getPort() or getPortById()

From: <bugzilla@jessica.w3.org>
Date: Wed, 26 Dec 2012 17:29:52 +0000
To: public-audio@w3.org
Message-ID: <bug-20505-5429-kZS6dxciqP@http.www.w3.org/Bugs/Public/>

--- Comment #7 from Chris Wilson <cwilso@gmail.com> ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Just wanted to record a random thought here:
> > > 
> > > getPort(DOMString id, optional MIDIPortType type);
> > > 
> > > As in: 
> > > var port = midi.getPort("12e23f3", "input");
> > 
> > But why would you do that? For any given id, the type is predetermined (and
> > fixed).
> Jussi said that the fingerprint might not be reliable (i.e., an input and
> and output would have the same fingerprint): "It would be especially
> annoying if faced with a UA that doesn't have enough data to give reliable
> fingerprints,  an application would've stored a fingerprint and assumed that
> the method would return an output port, but was given an input port instead,
> resulting in an error if it tried to send anything to it."

I don't believe the system would ever confuse an input and an output
fingerprint.  In my shim implementation, I'll simply prepend "i" or "o" to
identify.  The confusion potential with fingerprints is across sessions, when
you have multiple ports with the same name in the system, when the indices
change (e.g. when a device is added or removed from the system) - For example,
I have two Novation Launchpads (not an uncommon thing).  If I add a controller
that ends up (according to the OS) showing up in the list of interfaces before
those, suddenly one of those might be at index 5 instead of 4 - and the other
one is at index 4, and looks just like the other one used to in terms of name,
manufacturer, index... everything that persists.

> >     MIDIPort          getPort (MIDIPort or DOMString or short target);
> Sorry to again be a dumbass, but I really don't understand why you send a
> MIDIPort to get a MIDIPort? Can you please explain the logic there?

I would be happy to drop it.  I was simply copying out of the current spec.  I
think index (short) and id (string) are sufficient.

The MIDIPort type as a param predates the index; Jussi's original proposal had
MIDIPort, I believe.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Wednesday, 26 December 2012 17:29:53 UTC

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