org.freedesktop.PowerManagement

Havoc Pennington hp at redhat.com
Thu Mar 22 12:12:35 PDT 2007


Kevin Krammer wrote:
> On Thursday 22 March 2007 06:55 +0100, Thiago Macieira wrote:
>> Kevin Krammer wrote:
>>>> Yes, a dictionary might be nice, but it's not trivial to access in C.
>>>> This stuff really needs to be *trivial* for an application to access,
>>>> hence why I think booleans are probably best.
>>> How likely is an application written in C not going to use the D-Bus
>>> glib bindings?
>> Any library designed to be used by other languages.
> 
> Hmm, I thought that the main idea in D-Bus is to always use bindings.

This is the intent, but the GLib bindings for dict perhaps still need 
some work. Often a GHashTable is a lot more annoying in C than 
alternatives (like an array of pairs, or the raw libdbus iterator, or a 
custom object) - you don't see many designed-for-C APIs that pass 
GHashTable around. Even a GDBusDict type might be nicer since it could 
allow typesafe access and perhaps avoid copying the dict keys/values out 
of the DBusMessage (use the hash table only to speed up lookup, if there 
are say >10 key-value pairs, and otherwise avoid creating a hash table 
at all).

When designing a dbus interface maybe one should just assume bindings 
will evolve and improve and not try to optimize for details of current 
bindings.

(Don't get me wrong, I'm pretty sure the bitfield-vs-hash-vs-methods 
topic for this particular power management API has been a little 
overdicussed relative to its importance ;-) but the general lesson about 
improving hash table bindings in C might be worth thinking about more)

> How would one deal with D-Bus APIs that already use dictionationaries? Just 
> ignore those methods in wrappers?

Dictionaries certainly should be supported in bindings, I think it's 
broken if they aren't. Lots of times a dictionary is a very nice API 
since it allows you to have an extensible set of key-value properties 
for an object, among other things.

There's a standard Properties interface in the dbus spec that could be 
nicely extended by adding a call to get all the props in a dict in one 
go, and adding a change notification signal.

Havoc




More information about the xdg mailing list