Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Persistent port identifiers #34

Open
Boddlnagg opened this issue Dec 28, 2017 · 1 comment · May be fixed by #157
Open

Persistent port identifiers #34

Boddlnagg opened this issue Dec 28, 2017 · 1 comment · May be fixed by #157

Comments

@Boddlnagg
Copy link
Owner

Boddlnagg commented Dec 28, 2017

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
Copy link

Boscop commented May 12, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants