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

Ability to parse D-Bus configuration file(s) #78

Open
zeenix opened this issue Apr 29, 2024 · 1 comment · May be fixed by #159
Open

Ability to parse D-Bus configuration file(s) #78

zeenix opened this issue Apr 29, 2024 · 1 comment · May be fixed by #159
Labels
feature parity Feature parity with existing bus impls

Comments

@zeenix
Copy link
Collaborator

zeenix commented Apr 29, 2024

To be a drop-in replacement for the existing bus implementations, we need to be able to parse D-Bus XML configuration. Moreover, we should provide default files with easy method to install them as well (#77 should help with that).

@zeenix zeenix added the feature parity Feature parity with existing bus impls label Apr 29, 2024
This was referenced Apr 29, 2024
@jokeyrhyme
Copy link
Contributor

Work on this is included in #23 and #146

@jokeyrhyme jokeyrhyme linked a pull request Oct 27, 2024 that will close this issue
41 tasks
jokeyrhyme added a commit to jokeyrhyme/busd that referenced this issue Nov 30, 2024
jokeyrhyme added a commit to jokeyrhyme/busd that referenced this issue Dec 7, 2024
jokeyrhyme added a commit to jokeyrhyme/busd that referenced this issue Dec 9, 2024
We can deserialize an XML file using the "serde" and "quick-xml" crates.
Creating a struct type with nested structs within is a direct
approach that works well with `#[derive(Deserialize)]`. However, the
result isn't optimal for consumption, and also makes it very difficult
to implement aspects of the business logic that are sensitive to the
order of certain XML elements, e.g. `<bus>`, `<include>`, etc.

So our approach is to first deserialize into a `Vec<Element>` (inspired
by @elmarco 's work over in dbus2#23 ). Importantly, by starting with this
intermediate representation, we can preserve the XML author's intention
regarding the order of elements.

Then we replace any `<include>` and `<includedir>` elements with the
parsed contents the XML files to which they refer, further replacing any
`<include>` and `<includedir>` elements within those.

Finally, we can make one final iteration over the `Vec<Element>` to
produce the final optimally-structured `Config`.

Fixes dbus2#78
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature parity Feature parity with existing bus impls
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants