-
Notifications
You must be signed in to change notification settings - Fork 46
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
## Problem Agama's network model is heavily inspired by [nmstate](https://github.com/nmstate/nmstate/blob/c9fd1e80d3c87e1f844edcd86e9d36ae499ce717/rust/src/lib/ifaces/ethernet.rs#L64). Connections are represented [by an enum](https://github.com/openSUSE/agama/blob/2bc452b39e4460122ab52c5a72ee0d1dfe154cec/rust/agama-dbus-server/src/network/model.rs#L220) and each variant contains a struct which depends on the type (e.g., the [WirelessConnection](https://github.com/openSUSE/agama/blob/2bc452b39e4460122ab52c5a72ee0d1dfe154cec/rust/agama-dbus-server/src/network/model.rs#L542) struct). Those structs have a `base` field that points to a [BaseConnection struct](https://github.com/openSUSE/agama/blob/master/rust/agama-dbus-server/src/network/model.rs#L328) which holds the common fields for all connection types. And that's perfectly fine. However, we decided to introduce some methods to hide the fact that the common information lives in a separate `struct`. We could say it is for encapsulation reasons, but I don't know whether it is a good idea. Even we created some *getters* and *setters* for those fields, adding quite some [boilerplate](https://github.com/openSUSE/agama/blob/master/rust/agama-dbus-server/src/network/model.rs#L264-L299) [code](https://github.com/openSUSE/agama/blob/master/rust/agama-dbus-server/src/network/model.rs#L318-L324) Additionally, until we introduced the `ConnectionBuilder` (in #885), creating a new connection with some custom data (like an id and a UUID) was not straightforward because you needed to make the `BaseConnection` first (see [this example](https://github.com/openSUSE/agama/blob/2bc452b39e4460122ab52c5a72ee0d1dfe154cec/rust/agama-dbus-server/src/network/model.rs#L136-L141). ## Proposal Although I am not 100% sure whether it is a better idea, I am exploring the possibility of using a simpler layout to represent a connection. In this case, we would use a single `struct` containing the common fields plus a `config` field for specific stuff. That field contains an `enum` which represents each kind of connection. ```rust /// Represents an availble network connection #[derive(Debug, Default, Clone)] pub struct Connection { pub id: String, pub uuid: Uuid, pub mac_address: MacAddress, pub ip_config: IpConfig, pub status: Status, pub interface: String, pub match_config: MatchConfig, pub config: ConnectionConfig, } #[derive(Default, Debug, PartialEq, Clone)] pub enum ConnectionConfig { #[default] Ethernet, Wireless(WirelessConfig), Loopback, Dummy, } ``` And not getters/setters as they are not needed at all. ## Testing - Adapted the unit tested.
- Loading branch information
Showing
9 changed files
with
342 additions
and
470 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.