Re: Merging gio into glib

No issues with GIO being in GLib. I'm looking forward to working with GIO and gvfs.

So, I assume you're talking about the dbus/glib mainloop integration
library havoc mentioned. (Because if you think gvfs should use some shim
to allow you to replace the dbus implementation you're out of your mind.
It uses libdbus in very complex and specific ways which is highly
unlikely to work with other implementations, and anyway the shim would
be far to complicated.)

I didn't suggest a D-Bus implementation shim. My suggestion is to keep gvfs as a library outside of GLib so developers can choose whether to depend on it. This adds a little inconvenience for your users (an extra line in but solves the larger issue of avoiding multiple D-Bus implementations in one process for dozens of applications that are shipping today.

I've seen you campaining about this before, and I must say that I
totally disagree. I think Gtk+ needs to be a solid platform for what
"normal" UI applications need. This includes things like "disable
screensaver", which e.g. a presentation app or a movie player really
needs, and also things like stored application settings and (although
maybe less important) displaying notifications to the user. Now, clearly
the API should not expose dbus, nor would the implementation on win32
use dbus (so I don't understand why you bring up win32 portability?).
But there really needs to be a simple API for apps to do this.

We've discovered in the last year that portability is actually pretty important for a library like this. Managed D-Bus has been used to provide a notification-daemon on platforms like Win32 and OS X which don't have a practical built-in notification system. Until libdbus is portable, cross-platform applications are not going to drop managed D-Bus and switch back to libdbus.

If someone writes a pluggable libdbus backend that passes the test suite and doesn't break applications, we can re-evaluate this. I'm happy to review contributions like this.

In no way does it make sense to force apps to link against some other
library in order to do useful things like this (especially if the reason
is some weird lowlevel implementation detail). Not only does that
increase API complexity, it also means Gtk+ itself can't use these
features where it needs them (e.g. some widget might need to disable the
screensaver while doing something).

It's quite possible to do things like disabling the screensaver over X11. Not sure when it became fashionable to replace X functionality with D-Bus.

In fact, thinking about this, only using X properties or similar would provide the correct behaviour over remote displays. Can you explain why you don't want to use X here? Am really curious.

I see you played the mobile card too. I think that is totally bogus.
First of all dbus is pretty light (and is heavily used by current mobile
players), and secondly they control how they build their gtk+ libs. If
they need a different implementation of screensaver inhibition, or if
they just want to stub it out that is very easily done. In fact, such a
patch could go upstream and be easily selected using configure switches.

There was some interesting discussion on this subject recently from the Google Android developers. They use an IPC system called Binder which is right now implemented partly in-kernel. It gives them single copy shared memory IPC with management of object lifecycle across processes. Not saying they're not on crack, but it highlights the diversity of IPC systems in Linux-based mobile platforms, and I'd be surprised if they hadn't evaluated D-Bus before going with Binder.

Here's an old document pitting D-Bus against CORBA in performance:

Shows that D-Bus is not particularly light, so I do not know what you are talking about. The benefit of D-Bus has always been convenience, not lightness. Maybe you can share with us your findings to the contrary?

All this said, I think D-Bus is a great choice for most applications and GNOME. I'm just explaining why it's not yet a suitable dependency for GTK+ or GLib.

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