D-Bus best practices
thiago at kde.org
Mon Apr 20 12:32:04 PDT 2009
Em Segunda-feira 20 Abril 2009, às 19:13:45, Avery Pennarun escreveu:
> On Mon, Apr 20, 2009 at 12:40 PM, Schmottlach, Glenn
> <glenn.schmottlach at harman.com> wrote:
> > The reality, however, is that those folks who have tackled a
> > language/framework binding (like you) or actually implemented the D-Bus
> > reference implementation are probably in the best position to offer
> > advice on how to do things correctly.
> This is not exactly true. The people who've been doing it the longest
> probably know how to do things best, but the closer you become to a
> project, the harder it becomes to remember which parts other people
> find difficult.
> In my experience, the best documentation is written by people as
> they're learning, since they understand the problems of other people
> trying to learn.
> (If there are errors, well, someone can come in and fix them :))
I'd agree with that.
I don't know where I'd start. There are a couple of things that I can think of
because they show up very frequently either here or on the #dbus channel. But
other than that...
Anyways, here's a suggested list of topics to address:
It seems every month there's someone new running into x-comp. problems.
At least people seem to have figured out "make DESTDIR=.... install"
2) main-loop integration
If you want to receive spontaneous messages (such as signals or incoming
calls) and send messages, you have no other option than to use a mainloop
integration. Any other implementation (usually using the
dbus_connection_read_write call) either results in dead-locks or arbitrary
timeouts (waking up every 100ms or so).
Anybody using libdbus-1 is forced to write their XML for introspection and
has to do so manually. The library doesn't help you write the XML.
Worse yet: if you have a sub-hierarchy, you have to remember to add the
(In retrospect, the Introspect call should have returned "sas" so that the
list of sub-nodes is an easy-to-parse array, which could be added by the
library without expensive modification of the XML data)
4) discovery of services
I've seen many people introspecting the entire object path hierarchy in a
service or, even worse, all services, to find a given interface. That's the
wrong approach and we should encourage people to do it the right way: by
having a well-known path in a service and, if necessary, registering a well-
known service name too.
5) object lifetime (a.k.a. finding out when to release resources)
Best practices regarding listening for the NameOwnerChanged signal to decide
when a remote client has exited and, thus, a temporary object should be
released. Should also include some suggestions on how to explicitly notify
the server that the service is no longer necessary.
6) API design
a) roundtrips: D-Bus APIs should be designed for maximum information in the
smallest number of round-trips, so API designers should avoid making several
calls to collect information. It's cheaper to send information that isn't
necessary than to make extra calls for information that is.
b) timeouts: D-Bus method calls *do* timeout. There's no way around this, so
any call that can potentially take some time to execute should be designed in
a call/callback pattern: the call replies whether the action was initiated
and a signal reports the end result.
[This is an area where the protocol itself could use future improvement]
c) synchronous vs asynchronous API: the libdbus-1 library and most bindings
offer asynchronous method calls, which allow a call to be sent and other
operations executed while the call reply doesn't come. This is recommended to
avoid deadlocks when the callee can directly or indirectly call back to
complete its operation.
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Senior Product Manager - Nokia, Qt Software
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090420/f315d8dc/attachment.pgp
More information about the dbus