In 0.7 the Connection struct has been rewritten (but the old one is still there). The new struct(s) have the following advantages:
- It makes it possible to make a connection
Send/Sync, seeblocking::SyncConnection. - The call to
dbus_connection_dispatchhas been removed and what it did has been rewritten in Rust. This means better performance and panic safety. - The two-layer design (with
Channelas a low-level connection) makes it easier to write a customConnection, should that be necessary. - Preparation for a first class async/non-blocking
Connection. Anonblockmodule is in the works. - Some preparations for interfacing the
dbuscrate with a native backend instead of relying onlibdbus, should someone want to write such a backend. There is a lot more to do before that becomes a reality though.
If you want the quickest upgrade experience, then you can just update your imports:
- The old
Connectionis now atffidisp::Connection, likewise forConnPath,BusTypeand many others. Have a look at theffidispmodule to see if your struct has moved there. - The
stdintfmodule is atffidisp::stdintf. - The old
MessageItem, should you still need it, is now underarg::messageitem. But do use the generic functions instead ofMessageItemwhenever possible.MessageItem::DictEntryhas changed toMessageItem::Dict(which contains the entire dict, not just one entry) to make it less error prone.
On a long term, consider migrating / upgrading to blocking::Connection or blocking::SyncConnection. You would need to make the following adjustments:
- Create and connect your connection easily with just
Connection::new_session()orConnection::new_system(). - Instead of
ConnPath, use aProxy. It works approximately the same way. blocking::stdintfcan be helpful to make standard method calls, such as getting and setting properties on a remote peer.Connection::register_namehas been renamed torequest_name. (This was just a misnaming.)- Instead of
incoming()to process incoming messages, useprocess()(which takes a stdDuration). This will not hand out any messages though, instead register callbacks using (in order from most convenient to most generic):Proxy::match_signal,Proxy::match_startorchannel::MatchingReceiver::start_receive. - For
trees, you must now make sure the root path (/) is always part of your tree. - For
trees, callTree::start_receive()to attach the tree and the connection, then callConnection::process()to process incoming messages.
Have a look at the client, server and match_signal examples to get started.
The ReadAll and AppendAll traits were present in later 0.6.x versions as well, but are worthy a mention because they can make code more ergonomic in many cases. They are implemented for tuples: the empty tuple (), the single-tuple (TYPE,), and usual tuples (TYPE1, TYPE2) up to 11. So if you have a method call that takes STRING arg1, INT32 arg2 and returns a BOOLEAN, you can call it like this:
let (r,): (bool,) = myProxy.method_call(interface, name, (arg1, arg2))?;...where arg1 is a &str and arg2 is a i32.