Crates.io | zbus-lockstep |
lib.rs | zbus-lockstep |
version | |
source | src |
created_at | 2023-08-08 12:09:08.171218 |
updated_at | 2024-12-02 18:44:53.313071 |
description | Keep types in lockstep with DBus XML definitions |
homepage | |
repository | https://github.com/luukvanderduim/zbus-lockstep |
max_upload_size | |
id | 939079 |
Cargo.toml error: | TOML parse error at line 27, column 1 | 27 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
zbus-lockstep
helps keep type definitions in lockstep with DBus XML descriptions, using zbus-xml
.
It offers means to match your type's signature - <T as zvariant::Type>::signature()
- with a corresponding signature retrieved from a DBus XML file.
This way zbus-lockstep
prevents definitions from drifting apart.
In the context of IPC over DBus
- especially when there are multiple implementations of servers and/or clients - it is necessary for each implementation to send what others expect and that expectations are in accordance with what is sent over the bus.
The XML
protocol-descriptions may act as a shared frame of reference or "single source of all truth" for all implementers.
Having a single point of reference helps all implementers meet expectations on protocol conformance.
Keeping the types you send over DBus
in lockstep with currently valid protocol-descriptions will reduce chances of miscommunication or failure to communicate.
Add zbus-lockstep
to Cargo.toml
's dev-dependencies:
[dev-dependencies]
zbus-lockstep = "0.5.0"
Consider the followwing XML description, an interface with a single signal.
<node>
<interface name="org.example.Node">
<signal name="RemoveNode">
<arg name="nodeRemoved" type="(so)"/>
</signal>
</interface>
</node>
The type in our implementation might look like this:
#[derive(Type)]
struct Node {
name: String,
path: OwnedObjectPath,
}
The derive macro in this example implements the zvariant::Type
.
This means we can now call <Node as Type::signature()
, which will return a zvariant::Signature
of the type.
The test below shows how zbus-lockstep
may be used given what we know about the type.
use zbus_lockstep;
#[test]
fn test_get_signal_body_type_remove_node() {
let xml = PathBuf::from("../xml/test_definition_file.xml");
let iface = "org.example.Node";
let member = "RemoveNode";
let signature = get_signal_body_type(xml, iface, member, None).unwrap();
assert_eq!(signature, Signature::from_str_unchecked("(so)"));
}
Alongside the functions, macros are provided which - if the path to the definitions is known - can retrieve signatures more succinctly.
#[test]
fn macro_retrieve_signal_body_remove_node() {
std::env::set_var("LOCKSTEP_XML_PATH", "../xml");
use zbus_lockstep;
let sig = signal_body_type_signature!("RemoveNode");
assert_eq!(sig, zvariant::Signature::from_str_unchecked("(so)"));
}
When using XML descriptions as point of reference, you should ensure that the descriptions in use are always the most recent available.
Automated synchronizing would be preferred.
This crate started out as a fork of Tait Hoyem's zbus-xml-match.
MIT