Closed
Description
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.
- We don't have a match method that takes an
id
and returns a port. We should remove the mention of this. - 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 theopened
state). We can't encode this into theid
and so need another place to store it anyway. - Changing the
id
when paths change makes it difficult to use for equality. - 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.
Metadata
Metadata
Assignees
Labels
No labels