Re: using dbus in the platform


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 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: 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 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]