Re: Merging gio into glib

[Alp Toker <alp atoker com>]

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 configure.ac?) 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:

  http://eleceng.dit.ie/frank/rpc/CORBAGnomeDBUSPerformanceAnalysis.pdf

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.