using dbus in the platform
hp at redhat.com
Tue Oct 16 12:25:22 PDT 2007
The concerns you raised are:
- multiple implementations of dbus protocol are extra overhead
- multiple connections to the bus from a single process are extra
- multiple connections may be confusing semantically
Well, there is a proposal on the table to avoid multiple connections:
that is for everyone to share the same DBusConnection object from libdbus.
As I understand your proposal, it is to allow each app to provide its
own "gtk-to-dbus bridge" to GTK+ at runtime, with the idea being that a
C# app would provide such a bridge written in C#, and a Python app would
provide one written in Python, and so forth.
Unfortunately, a gtk-to-dbus bridge will simply be a dbus library. gvfs
*also* uses dbus in arbitrary ways, and GTK will potentially use dbus in
arbitrary ways. So, a gvfs/gtk-to-dbus bridge would be a complete C dbus
API, not some limited API.
So what your proposal boils down to is to have a complete C dbus API,
with a pluggable protocol parser and connection queue on the backend
that can be written in any language.
Alp Toker wrote:
> The ideas being thrown about involved pre-loading a module that would
> provide IPC functionality, rather than a hard-coded dependency on D-Bus.
To make this more concrete, see the patch I posted with GtkDesktop.
(the use of dbus is not coded yet, though, but it should be obvious
where it would slot in)
> The functionality is welcome, but it should be provided in a separate
> library, just like gvfs.
> Is there any technical reason why it needs to be included in GTK+? Does
> it make use of GTK+ internals? I suspect not.
gvfs and gtk need to *depend* on being able to use dbus. That means they
have to depend on a dbus C API. Now, the dbus C API could be a wrapper
around a pluggable dbus implementation written in Python, C#, or
whatever; but, I don't understand why that makes sense at all. It is
backward from how we do language bindings in every other case.
The reason we do language bindings with everything else wrapping C,
instead of vice versa, is to avoid implementing everything N times, once
> libdbus was not well-suited to language binding when I reviewed its
Well, you should ask questions. All problems I know of are either
fixable, or due to a misunderstanding of how to use the API.
For example, people had issues with reference count cycles. This is an
already-solved problem with GObject, using toggle references. As soon as
someone asked about the issue, I knew about the GObject solution and was
able to suggest it for libdbus.
Another example, you mention the abort behavior on violations of the API
contract; GTK has the same behavior, you know, though it does not abort
by default, behavior is undefined by default once the API contract is
violated, and can be configured via env variable to abort. libdbus
aborts by default, but can be configured via env variable to have
undefined behavior instead.
You should not be shipping code that *either* aborts or triggers
For *both* GTK and libdbus, it is a bug in a binding if these API
contract violations are triggered. In both cases, there is no way to
throw a C# or Python exception due to triggering them. If you want to
throw an exception you have to catch *and avoid* the API contract
violation prior to calling in to GTK or libdbus. The fact that GTK is
undefined instead of aborting immediately does not mean it is OK to
violate the API contract.
(This of course is exactly why libdbus aborts, because with the GTK
behavior people think it is somehow more permissible not to fix their
code. The libdbus way is intended to force you to understand the
difference between an API contract violation and a recoverable error,
which is also documented in the GLib manual:
and I tried another way to explain it here:
I don't think you understand the distinction here and what the libdbus
and GTK API contracts are, because if you did, you would not see a
difference in your responsibilities when binding libdbus and binding GTK.
If you do think undefined behavior is somehow OK, then set the env
variable when using libdbus to turn off abort and turn on undefined
behavior. You can even do a putenv() in your binding, though I think
that's pretty strange.
In any case, another branch of this thread (on dbus list only) already
discussed solving this problem. The solution includes 1) it is a bug if
libdbus has API contract violations that you can't avoid or have to
write tons of code to avoid and 2) we can have a convenience API shared
by language bindings that does more precondition checks, if people want.
There is no reason, bottom line, that you should ever trigger an API
You briefly refer to "necessary entry points for
marshalling/demarshalling data" and "encouraged consumers to disconnect
shared connections"; I am not sure what either of those mean, but if you
want to post a description of the problems I am happy to either clarify
how to use the API or fix it.
> If "DBusConnection" is so easily shared, why are various language
> bindings today opening private, unshared connections to the bus? It is
> evident that reality has not matched expectations here.
And you think having gvfs and gtk use a C dbus API that has pluggable
backend implementations written in 5 different languages is going to help?
dbus-glib does not use a private connection. QtDBus did, but as
discussed in earlier threads, it did not have to; the issue was that
Thiago did not fully understand how to use the libdbus API. (And now it
would be some work to retroactively adjust how QtDBus works.) I am not
sure of the current dbus python status on this, but I don't remember
hearing any good reason it could not use the shared connection. All I
remember were some bugs or missing API or other easily-fixable item.
The fact is that addressing any shared connection issues is easy, much
easier than the alternatives, and that problems with it in the past have
been due either to bugs or misunderstandings.
> In my experience with libdbus, I've found that it sets low standards for
> interoperability and fails to achieve them.
All of the problems you have mentioned specifically are simple problems.
Inventing a whole new C dbus API that *wraps* multiple APIs written in
other languages is *not* a simple problem.
> Given these realities, I cannot see how libdbus in its current state
> could be an appropriate dependency for GTK+.
I don't think saying "realities" is accurate at all. libdbus uses pretty
much exactly the same API conventions as the rest of the GLib/GTK+ stack.
More information about the dbus