antoyo / dbus-macros-rs Goto Github PK

In certain places we have unwraps and that will make the client code stop, which is not at all desirable so we should handle the results better.

Would be great if the readme showed an example with dictionaries. Trying to figure that out now.

The DBus convention is to always CamelCase method names but Rust convention is small letter + underscores (you actually get even a warning from rustc about it). Vala has exactly the same so it automatically converts the case for you and I think we should do the same in here.

When dbus crate starts supporting asynchronous calls, we must support that, especially for client-side.

dbus-macros uses dbus 0.4.1 and upstream is 0.5.2

To make clear what this actually means and what it is good for

D-Bus supports multiple out parameters so macros should support that too.

How does one use or install this library?

The macros to create a service, currently assume that only one object/interface is served on the network. If one needs to serve multiple objects on the bus, they need to launch threads etc, which is cumbersome. We should allow for multiple objects to be served from the same thread easily.

The API currently creates a new connection object for each object/interface, which is not what dbus client code typically wants and leads to hard to debug issues:

avahi/avahi#114

Instead dbus-macros should require an Rcdbus::Connection be provided instead, by the caller.

While trying to use dbus-macros to communicate with Avahi, I ran into two issues. This was the second one. If I understood the macro definition correctly, the path is assumed to be the same as the name of interface, which is not always the case. Also a lot of times you get the path dynamically on the fly. E.g in Avahi, to publish a service you need to call EntryGroupNew on 'Server' object, which lives on "/" path, while it's interface is "org.freedesktop.Avahi.Server".

Macros aren't very useful if we don't support D-Bus properties, some APIs are very props-based.

While trying to use dbus-macros to communicate with Avahi, I ran into two issues. This was the first one. I need this interface for example that is currently not possible with limit on number of arguments to dbus methods:

dbus_interface!("org.freedesktop.Avahi.EntryGroup", interface EntryGroup {
fn add_service(ifindex: i32,
protocol: i32,
flags: u32,
name: &str,
service_type: &str,
domain: &str,
host: &str,
port: u16,
text: &str);
});

I have the following code (it assume the PR i submitted earlier):

use dbus;
use dbus_macros;

dbus_interface!("org.freedesktop.Avahi.Server", interface Server {
    fn EntryGroupNew() -> String;
});

pub fn publish() -> Result<(),dbus::Error> {
    let server = Server::new("org.freedesktop.Avahi", Some("/"), dbus::BusType::System);

    // FIXME: Make this async when it's possible
    let group_path = server.EntryGroupNew()?;
    println!("group: {}", group_path);

    Ok(())
}

But I get an error on runtime:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:323
stack backtrace:
   1:     0x56297977b49a - std::sys::imp::backtrace::tracing::imp::write::hd9cb4c1797101742
   2:     0x56297977d802 - std::panicking::default_hook::{{closure}}::h154dea97b11a961f
   3:     0x56297977d3d7 - std::panicking::default_hook::h7b2373844128ce08
   4:     0x56297977dbf1 - std::panicking::rust_panic_with_hook::h8d52d23c1df454da
   5:     0x56297977da34 - std::panicking::begin_panic::h031e0a076e248818
   6:     0x56297977d9a9 - std::panicking::begin_panic_fmt::hcd972326ec953c01
   7:     0x56297977d937 - rust_begin_unwind
   8:     0x562979787cbd - core::panicking::panic_fmt::h519452995771b90d
   9:     0x562979787bf4 - core::panicking::panic::h22b1ce4468ab1d51
  10:     0x56297974bdb9 - <core::option::Option<T>>::unwrap::haf3c34ffc6e2f4b0
                        at /builddir/build/BUILD/rustc-1.15.1-src/src/libcore/macros.rs:21
  11:     0x5629797595de - gps_share::avahi::Server::EntryGroupNew::h9d39588b9afb2632
                        at /home/zeenix/checkout/gnome/gps-share/src/avahi.rs:27
  12:     0x562979758713 - gps_share::avahi::publish::heb15ba5d63934b45
                        at /home/zeenix/checkout/gnome/gps-share/src/avahi.rs:48
  13:     0x562979757efb - gps_share::server::Server::run::he7c19064abce934d
                        at /home/zeenix/checkout/gnome/gps-share/src/server.rs:46
  14:     0x562979758e57 - gps_share::main::h38c6f0d6672ea359
                        at /home/zeenix/checkout/gnome/gps-share/src/main.rs:52
  15:     0x5629797860ea - __rust_maybe_catch_panic
  16:     0x56297977e1d1 - std::rt::lang_start::h654cbbacaf320c39
  17:     0x562979759802 - main
  18:     0x7fc5957a9400 - __libc_start_main
  19:     0x56297974aef9 - _start
  20:                0x0 - <unknown>

I checked on busctl monitor and saw the method successfully returning a string, as expected. So it's something with the macro.

Just like properties, we should also provide easy way to declare, emit and receive D-Bus signals, just like in Vala: https://wiki.gnome.org/Projects/Vala/Tutorial#Signals

Currently clients have no way of catching the errors from their dbus callls and service implementation have no way of throwing errors at clients. We need to change this.