#dbus #zbus #ipc #type-safety

macro zbus-lockstep-macros

Macros to keep types in lockstep with DBus XML definitions

12 releases

0.5.0 Dec 2, 2024
0.4.4 Mar 18, 2024
0.4.0 Feb 19, 2024
0.3.1 Oct 2, 2023
0.2.0 Aug 31, 2023

#1036 in Procedural macros

Download history 56/week @ 2024-08-30 19/week @ 2024-09-06 25/week @ 2024-09-13 23/week @ 2024-09-20 23/week @ 2024-09-27 4002/week @ 2024-10-04 8966/week @ 2024-10-11 10278/week @ 2024-10-18 14149/week @ 2024-10-25 22073/week @ 2024-11-01 20650/week @ 2024-11-08 20351/week @ 2024-11-15 20622/week @ 2024-11-22 23511/week @ 2024-11-29 23280/week @ 2024-12-06 21703/week @ 2024-12-13

92,338 downloads per month
Used in 61 crates (via atspi-common)

MIT license

68KB
961 lines

zbus-lockstep-macros

CI Maintenance crates-io api-docs

zbus-lockstep-macros extends zbus-lockstep to match the signature of signal types <T as zvariant::Type>::signature() with a corresponding signature from a DBus XML file more conveniently and succinctly.

Motivation

In the context of IPC over DBus, especially where there are multiple implementations of servers and/or clients communicating, 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.

Use

Add zbus-lockstep-macros to Cargo.toml's dependencies:

[dependencies]
zbus-lockstep-macros = "0.5.0"

If the DBus XML descriptions can be found in the crates root, in either xml/ or XML/, validating the type can be as easy as:

 use zbus_lockstep_macros::validate;
 use zvariant::Type;

 #[validate]
 #[derive(Type)]
 struct BirthdayEvent {
    name: String,
    new_age: u8,
}

Note that the macro assumes that the member name is contained in the struct name. You can provide the member name if you have another naming-scheme in use.

Also, it may be necessary to disambiguate if multiple interfaces across the DBus descriptions provide signals with the same name.

Any of the arguments are optional.

#[validate(xml: <xml_path>, interface: <interface_name>, member: <member_name>)]

See also the crates docs for more detailed descriptions of the arguments.

LICENSE

MIT

Dependencies

~5MB
~97K SLoC