Clarfiy opaque id field for MIDIPort text in spec

[agoode]

The current text for id reads as:

It is expected that the system will do the best it can to match a port across instances of the MIDI API: for example, storing the port interface manufacturer, name and index in the id, and attempting to find any ports with that name to consider as a match. Applications may use the comparison of id of MIDIPorts to test for equality.

There are a few problems here.

1. We don't have a match method that takes an id and returns a port. We should remove the mention of this.
2. In order to make persistent identifiers robust against limitations of USB (example: http://lists.apple.com/archives/coreaudio-api/2009/Aug/msg00023.html), both the hardware's properties and the connected USB socket must be remembered. The connected USB socket may change and be updated in the system from time to time. We do not want to change the id every time this happens (which can happen even while the port is in the opened state). We can't encode this into the id and so need another place to store it anyway.
3. Changing the id when paths change makes it difficult to use for equality.
4. If we actually do encode the info into the id, we might be leaking too much information. Here is a format I was experimenting with to encode enough info on Linux for persistence: {"addr":"24:0","canInput":true,"canOutput":true,"clientName":"QX25","name":"QX25 MIDI 1","udev":{"id_id":"usb-Alesis_QX25_STM3210-00-QX25","id_path":"pci-0000:00:14.0-usb-0:1:1.0"}}. We probably don't want to give all this info to web sites.

We should recommend that id be opaque and backed by an internal mechanism that does its best to follow devices as they move.

[toyoshim]

For 1, isn't it enough to use inputs and outputs in MIDIAccess? That's maplike<DOMString, MIDIPort>, and the key DOMString is id.

[agoode]

With maplike, I think we are required to use string equality for the keys, correct?

If so, then I can't hand out an id with extra data and/or hints embedded in it, which I need to help me find a match of the hardware.

Here is a concrete scenario with non-opaque ids:

1. Device with hardware id A1 plugged into USB port P1.
2. id = {"hardwareId":"A1", "hardwarePath":"usb-P1"}
3. Client saves id away in a cookie.
4. The device is unplugged and replugged. It is now in USB port P2.
5. The old id in the cookie should be valid, since I can find the correct device with high confidence, but it doesn't match the new key in MIDIAccess: {"hardwareId":"A1", "hardwarePath":"usb-P2"}, so the client can't find the port. (The client doesn't know how to do the implementation-dependent match.)

So we can provide a separate match function that takes an id and gives a new id (or null) of something guaranteed to be in MIDIAccess. But to avoid another method, we can just make the id opaque.

[toyoshim]

I think we should not expose physical information detail that indicates device connection tree in favor of privacy concern. Another extreme idea on the port id vs privacy is #48. So the id is expected to be some kind of hash that is generated from information, hardwareId, hardwarePath, and so on in your case.

When a user reconnect the same device to another USB port, a user may expect that the device is identified as a different one, or at least he/she will accept the truth that system can not identify the device as expected. Rephrasing it, if I want to use the same two devices on DAW, I will handle them carefully so that the DAW can handle them correctly. I will never expect that DAW can handle it correctly when I swapped the connected port. I think your use case that the same port in different port should be identified as the same device is not common. Also, in such use case, a user may want to use name+manufacturer+version.

[cwilso]

1. As Takashi-san says, this is essentially what maplike id does.
2. I think Windows and OSX will do this for you, and in other systems I'd expect you to cache the data; but honestly, it's a should, not a must, on purpose.
   3/4. It should be opaque to the user - i.e., it should be a hash or some such lookup.

[agoode]

Ok. I think I see how the text makes sense for point 1. Thanks for bearing with me.
Is it worth updating the text and removing the example of "storing the port interface manufacturer, name and index in the id"? It seems we do want to encourage a hash or other opaque string for the id.

[bome]

👍 for hash. Maybe the example could state that the implementation could create a hash of port interface manufacturer, name and index for creating the id?

[cwilso]

Sure. That was what I meant when I wrote it, but it is clearly not saying that. :)