Conversation
* It only exports the ids.
|
Changes unknown |
mvidner
left a comment
There was a problem hiding this comment.
I'm being extra pedantic about API naming consistency here...
The aspects to observe are
- pluralization
- capitalization
For pluralization, it makes sense to use the plural name whenever there is a collection: /.../things and /.../things/1, /.../things/33 (as opposed to the singular /.../thing/33)
For capitalization,
- the Naming Conventions want to use CamelCase even for objects
- here we are following the systemd convention of naming the objects in lowercase
- other parts of Agama use CamelCase for object names
IMHO we should use CamelCase
(but before reaching this conclusion I have adjusted the docs to document the code reality)
| .connections_paths() | ||
| .iter() | ||
| .filter_map(|c| ObjectPath::try_from(c.clone()).ok()) | ||
| .collect() |
There was a problem hiding this comment.
NP: I've found that the resulting array is not sorted, at least not by ObjectPath
| /// Adds a new network connection. | ||
| /// | ||
| /// * `name`: connection name. | ||
| /// * `ty`: connection type (see [crate::model::DeviceType]). |
There was a problem hiding this comment.
FWIW, the argument name is exposed in D-Feet and my first thought was: "Ty... pe? Why the truncation?"
Using type_ is slightly awkward, but https://docs.rs/zbus/3.12.0/zbus/attr.dbus_interface.html doesn't let us name parameters freely so it is IMHO the best option.
| /// Adds a new network connection. | ||
| /// | ||
| /// * `name`: connection name. | ||
| /// * `ty`: connection type (see [crate::model::DeviceType]). |
There was a problem hiding this comment.
About the value of the type argument:
It should be documented where the D-Bus API user can easily reference it.
So I'm going to add /doc/dbus/*Network1*.doc.xml files and document it there.
| objects | ||
| .devices_paths() | ||
| .iter() | ||
| .filter_map(|c| ObjectPath::try_from(c.clone()).ok()) |
There was a problem hiding this comment.
In a strongly typed language I would expect the object paths to be always valid, unless coming as user input or as arguments to a constructor, which is not the case here.
| } | ||
|
|
||
| /// Returns all devices paths. | ||
| pub fn devices_paths(&self) -> Vec<String> { |
There was a problem hiding this comment.
We should be using specialized strings that are guaranteed to be valid object paths.
The zbus_names crate exists exactly for this purpose and... it does not include object paths... because they appear on the wire so the type lives in zvariant.
So,
use zvariant::ObjectPath;
pub fn devices_paths(&self) -> Vec<OwnedObjectPath> {
or
pub fn devices_paths(&self) -> Vec<ObjectPath> {here and in many other places.
With respect to the D-Bus API it is an implementation detail, so we can leave it for later.
BTW I don't have a source for this, it is "original research" 😄 and the reasoning is that the tree is more compact when we use the same word forms for both the "manager" and the "items" |
jreidinger
left a comment
There was a problem hiding this comment.
OK, so now after updates only important stuff for me is DBus naming ( consistency and that ty as property ). And in general I would like to see type_ instead of ty as mvidner agrees with me :) Others can wait for next PR
Co-authored-by: Martin Vidner <mvidner@suse.cz>
I would say we are using systemd capitalization style in new code (basically in storage). We could re-evaluate that decision but, at least, we should document why we went that road (and plan for adopting it in the rest of the APIs). |
OK, I still do not like I have found more usages of
However, I can understand that it looks weird, so I have renamed it by now to unblock this PR. |
Co-authored-by: Martin Vidner <mvidner@suse.cz>
mvidner
left a comment
There was a problem hiding this comment.
Thank you!
Just a .changes entry is missing I think
Oops, good point. I will add it. |
Problem
Agama does not offer a service to set up the network. The web UI talks directly to NetworkManager and the CLI/autoinstallation does not support configuring the network.
Solution
Trello card: https://trello.com/c/1kiDu6yN/ and https://trello.com/c/TCJqEQ2z/
This PR introduces a new service that allows configuring the network. The code is organized into these modules:
modelcontains the types that represent the network concepts. They are supposed to be agnostic from the actual network service (e.g., NetworkManager).adapteroffers an abstraction to support other backends in the future (if needed).dbusincludes the D-Bus service implementation.nmimplements support for interacting with NetworkManager.Example of a network D-Bus tree
Exposing a wireless network
Documentation
This PR updates the network_support_design.md document, as we decided not to rely on third-party tools (that's the reason the branch is called
network-service-2😅).In addition to that, we tried to document the code to make it easier to contribute.
Library documentation
Testing
As with most of our Rust code, it contains a few unit tests. I will try to add more before merging.
Why is it still in draft mode?
agama-dbus-serverpackage (see Rust locale #533).Reportstruct).What's next?