search

Boddlnagg / midir

Cross-platform realtime MIDI processing in Rust.
MIT License
609 stars 75 forks source link

Persistent port identifiers #34

Open Boddlnagg opened 6 years ago

Boddlnagg commented 6 years ago

This is a follow-up to #32. See the WebMIDI spec for a neat description of a "persistent port ID" (https://www.w3.org/TR/webmidi/#attributes-1):

This can be used by developers to remember ports the user has chosen for their application. The User Agent MUST ensure that the id is unique to only that port. The User Agent SHOULD ensure that the id is maintained across instances of the application - e.g., when the system is rebooted - and when a device is removed from the system. Applications may want to cache these ids locally to re-create a MIDI setup. Some systems may not support completely unique persistent identifiers; in such cases, it will be more challenging to maintain identifiers when another interface is added or removed from the system. (This might throw off the index of the requested port.) It is expected that the system will do the best it can to match a port across instances of the MIDI API: for example, an implementation may opaquely use some form of hash of the port interface manufacturer, name and index as the id, so that a reference to that port id is likely to match the port when plugged in. Applications may use the comparison of id of MIDIPorts to test for equality.

This implies that we support Eq and Hash, and maybe even serde's serialization traits (with an optional feature).

It is still unclear whether the persistent ID should replace or be added on top of the non-persistent ID implemented in #32. Because the IDs from #32 are opaque, they can be changed internally as needed.

Boscop commented 4 years ago

The IDs can be opaque (in the type system) but still be serializable in app's config data, that should work.. Then if the repr changes, it will fail to deserialize, and then the user has to choose the port again. But that won't happen often.