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

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20505

Jussi Kalliokoski <jussi.kalliokoski@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jussi.kalliokoski@gmail.com

--- Comment #2 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> ---
(In reply to comment #1)
> 1) The separation between these is because they are, in fact, two different
> lists (inputs and outputs), and they're fundamentally different objects; one
> can only read, one can only write.  Merging these entirely will, I think,
> tend to be confusing, as output ports will have an onmessage handler, and
> input ports will have a send() method, even though they are orphans that
> don't do anything.  I'm not very comfortable with that, as I think the guard
> rails (guide rails?) of having the methods only where appropriate is good.
> 
> On why there are three methods to get an input/output - personally, I'd
> ditch the MIDIPort version, but I do want to keep the index version, as (if
> you look at most of my demos), it's fairly common to show a dropdown to
> select ports, and index is an easy way to do that.  No, it won't persist
> over sessions, but it doesn't need to.  In fact, if you were persisting over
> sessions, I'd expect an app to pop "pick your port" dialog that is
> index-based, and then persist the ID.

I agree with Chris, the port types (input, output) are very different, and
having the MIDIPort interface as separate from those two helps with the fact
that you don't have to capture the devices when you enumerate (e.g. winmm
grants only one program exclusive, and exclusive only, access per MIDI device).

As for the getInput/getOutput merging, I'm quite fine with reducing the
overloads to just the ID, the use case Chris mentioned is as simple and better
handled with IDs anyway, to be more resilient to live hardware changes:

inputSelect = document.createElement('select')
document.body.appendChild(inputSelect)

midiaccess.enumerateInputs().forEach((input) => {
  var elem = document.createElement('option')
  elem.value = input.id
  elem.innerHTML = input.name
  inputSelect.appendChild(elem)
})

inputSelect.onchange = function () {
  var input = midiaccess.getInput(this.value)
}

But I'm not sure it's a good idea to merge the two different methods, unless we
want to add a mandatory constraint that the fingerprint/ID needs to be
different for input devices and output devices. 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 25 December 2012 23:48:50 UTC