GNOME Bugzilla – Bug 682053
settings: The 'master' option should accept 'id'
Last modified: 2013-01-14 13:32:52 UTC
The only identification specified by the user is the text field 'id'. It feels natural to be able to use this as identification for the 'master' option of slave connections. Unfortunately, it only supports interface name and 'uuid'. Imagine for example that you are building VLAN over a Bridge over a Bond of interfaces. From the docs: master string Interface name of the master device or UUID of the master connection While uuid has a specific distinguishable format, 'id' can't be distinguished easily from interface name. There are two main approaches to solve this: 1) Prefer 'id' names. This is only natural to prefer the configuration names over interfaces. 2) Prefer interface names. This is 100% backwards compatible even for the corner case of using conflicting names for different connections. Users should never do that, though. Of course the third way is to keep the current behavior and make 'id' a second-class citizen.
IDs are supposed to only be a human readable identifier for a connection, and not used anywhere internally since multiple connections can have the same ID, for example if different users have connections that are visible only to them and call them the same thing. That's perfectly valid. And this is exactly what the UUID is for. So if you ignore that problem entirely, I don't have an issue with using the connection ID in the *user interface*. eg use it in config files, but have the config plugin look up the UUID from the human-readable ID and substitute it when necessary. But the ID shouldn't be used for any logic past the UI boundary. So the 'master' option should not accept an ID, but perhaps the plugins could do the lookup from ID -> UUID. You'll still have to figure out how to deal with connection name clashes if you have two connections with the same ID, since we don't restrict IDs in any way right now, and we don't even care if two connections (with different UUIDs of course) have the same ID even for the same user.
Sounds reasonable. We'll have to deal with it in nmcli and other interfaces. Not sure about D-Bus, though.