using dbus in the platform

[Havoc Pennington]

Hi,

The concerns you raised are:

  - multiple implementations of dbus protocol are extra overhead
  - multiple connections to the bus from a single process are extra
    overhead
  - 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.
http://mail.gnome.org/archives/gtk-devel-list/2007-October/msg00025.html

(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 
per language.

> libdbus was not well-suited to language binding when I reviewed its 
> documentation.

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 
undefined behavior.

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: 
http://library.gnome.org/devel/glib/unstable/glib-Error-Reporting.html 
and I tried another way to explain it here: 
http://lists.freedesktop.org/archives/dbus/2007-October/008680.html)

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 
contract violation.

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.

Havoc