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
_______________________________________________
xdg mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/xdg
