D-Bus best practices

[Thiago Macieira]

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:
 1) cross-compilation
	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).

 3) introspection
	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 
	<node> elements.
	(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
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/dbus/attachments/20090420/f315d8dc/attachment.pgp