There are several cases where data is stored in strings, where a more precise type would be more appropriate. I have tried to collect all of these, along with suggestions for the type. Some of these have obvious representations from third party crates, and some less so, and of course we should be wary of adding public dependencies
Connection UUIDs
Connection UUIDs are currently stored as strings, but as the name suggests they are guaranteed to be a valid UUID. The UUID crate is ubiquitous and stable, so I think this would be the right type to use.
This could also be used for BSSIDs
Mac Addresses
The simplest solution would be to use the macaddr crate, which provides both EUI-48 and EUI-64 formats. I'm not well versed enough to know whether NetworkManager will ever return an EUI-64 address, but either the MacAddr struct or MacAddr6 enum would work.
IP Addresses
NetworkManager generally returns IP Addresses in CIDR format, and from my search I couldn't find a crate that simply stores the address and prefix together, so I think having our own version would be best. This could be in the form:
pub struct Ipv4Address {
pub address: Ipv4Addr,
pub prefix: u8,
}
pub struct Ipv6Address {
pub address: Ipv6Addr,
pub prefix: u8,
}
There's potentially a future discussion to have about any additional features of these structs, e.g. Should they implement Eq or Ord, and should those implementations take into account the prefix?
Timestamps
SavedConnection has a timestamp_unix field. It may be worthwhile to use something like Chrono or jiff to represent this. Since there isn't necessarily an ecosystem consensus on this, this probably shouldn't be a priority
Paths
SavedConnection also has a filename property. It may be better to store this as a PathBuf instead
Priority Maps
VlanConfig has ingress_priority_map and egress_priority_map. The mapping may be better represented by a struct containing to and from fields
Enums
There are various string fields which may be better as enums. A (non-exhaustive) list is here:
There are several cases where data is stored in strings, where a more precise type would be more appropriate. I have tried to collect all of these, along with suggestions for the type. Some of these have obvious representations from third party crates, and some less so, and of course we should be wary of adding public dependencies
Connection UUIDs
Connection UUIDs are currently stored as strings, but as the name suggests they are guaranteed to be a valid UUID. The UUID crate is ubiquitous and stable, so I think this would be the right type to use.
This could also be used for BSSIDs
Mac Addresses
The simplest solution would be to use the macaddr crate, which provides both EUI-48 and EUI-64 formats. I'm not well versed enough to know whether NetworkManager will ever return an EUI-64 address, but either the
MacAddrstruct orMacAddr6enum would work.IP Addresses
NetworkManager generally returns IP Addresses in CIDR format, and from my search I couldn't find a crate that simply stores the address and prefix together, so I think having our own version would be best. This could be in the form:
There's potentially a future discussion to have about any additional features of these structs, e.g. Should they implement
EqorOrd, and should those implementations take into account the prefix?Timestamps
SavedConnectionhas atimestamp_unixfield. It may be worthwhile to use something likeChronoorjiffto represent this. Since there isn't necessarily an ecosystem consensus on this, this probably shouldn't be a priorityPaths
SavedConnectionalso has afilenameproperty. It may be better to store this as aPathBufinsteadPriority Maps
VlanConfighasingress_priority_mapandegress_priority_map. The mapping may be better represented by a struct containingtoandfromfieldsEnums
There are various string fields which may be better as enums. A (non-exhaustive) list is here:
SavedConntion.connection_typeSettingsSummary::Wifi.modeSettingsSummary::Wifi.bandSettingsSummary::Wifi.mac_randomizationSettingsSummary::Gsm.pin_flagsSettingsSummary::Cmda.password_flagsSettingsSummary::Bluetooth.bt_typeWifiSecuritySummary::eap_methodsBluetoothDevice.bt_capsNetworkInfo.modeNetworkInfo.securityNetworkInfo.statusSavedConnectionBrief.connection_typeVlanConfig.flagsVpnDetails::OpenVpn.protocol