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

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

--- Comment #3 from Marcos Caceres <w3c@marcosc.com> ---
(In reply to comment #2)
> 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).

Ok, my objection was purely based on having to add more objects to the global
scope (i.e., all WebIDL interfaces end up on the Window object... but c'est la
vie). From an authoring perspective, it makes little difference and Chris' is
right in that it may avoid some confusion.  

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

I'm of the opinion that one should go for "the ideal" solution first, then
backtrack if it fails. In this case, it would mean getting some implementation
experience to see if we can get unique fingerprints. 

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

Agreed. But as I said above, at this stage in the standardisation game, it does
not hurt to see if that problem can be solved somehow. 

Having said that, we should add a big red note to the spec asking implementers
for feedback exactly about this.

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

Received on Wednesday, 26 December 2012 00:14:26 UTC