using dbus in the platform

Simon McVittie simon.mcvittie at collabora.co.uk
Tue Oct 9 09:20:42 PDT 2007


On Tue, 09 Oct 2007 at 11:45:29 -0400, Havoc Pennington wrote:
> Simon McVittie wrote:
>> However, to make a decent Python binding, libdbus will have to get
>> better at being wrapped in high-level languages (the "everything returns
>> a DBusError, nothing aborts for reasons that can't be checked for"
>> approach that libdbus explicitly doesn't follow at the moment). Would
>> you accept patches that improve libdbus' behaviour in that respect?
>
> I think there's a way to do this, yes, but we have to be careful about how. 
> I have a vague idea that needs more elaboration, I will give you the vague 
> version.
>
> First the problem statement: we want to share code among language bindings 
> that checks for bugs in app-provided args or data, so those bindings can 
> throw an exception.

I think it's reasonable to distinguish between easy and hard checks.
Language bindings should by all means be checking for easy things like
"the argument isn't NULL".

It's debatable whether they should be checking for things that can be checked
synchronously and without race conditions, like an object path being
syntactically valid (dbus-python had to NIH validation for that sort of thing
because libdbus doesn't provide it).

libdbus should certainly be taking responsibility for things that it's
hard for the binding to get right, like "there's already a handler for this
object path".

> I'm not sure about the naming ("checked") - that may not make sense for all 
> functions.

I'd tend to go for NAMESPACE_try_VERB, which is quite concise, reminds
the reader of try/catch or try/except blocks in most languages with
exceptions, and has the right implication of "try to do this, but if you can't,
let me know rather than panicking".

I've done an implementation of dbus_connection_try_register_object_path and
dbus_connection_try_register_fallback (attached).

Something that might be useful to adopt from GLib is that passing in a
NULL DBusError* should be allowed, in the same way that a NULL GError*
is allowed - it means "I don't care about any failure, probably because
I happen to know that only OOM can happen". That way, new API can be
provided in the more complex form only, and the caller can just pass
NULL if they know it won't fail for non-OOM reasons.

It'd also be good to be able to avoid calling dbus_error_init() all the
time, by providing a DBUS_ERROR_INITIALIZER macro:

/* in dbus-errors.h */
#define DBUS_ERROR_INITIALIZER { NULL, NULL, 0, 0, 0, 0, 0, NULL }

/* in user code */
DBusError error = DBUS_ERROR_INITIALIZER;

Regards,
	Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-dbus_connection_try_register_object_path-and-dbu.patch
Type: text/x-diff
Size: 14348 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20071009/ad806dee/attachment.patch 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 266 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/dbus/attachments/20071009/ad806dee/attachment.pgp 


More information about the dbus mailing list