Re: Merging gio into glib

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-11-14 at 14:56 +0000, Alp Toker wrote:
> 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.

gvfs today will automatically work for everyone that correctly uses the
gio APIs. Seems much better than forcing all developers to add some
configure.ac stuff. 

But yes, gvfs moves the dbus dependency outside glib. In practice
though, the goal is to get everyone (on unix) to ship gvfs, and since
Gtk+ will use the gio apis directly (e.g in the file selector) this
means that all Gtk+ apps will be linking to libdbus. (Of course, users
could still opt not to install gvfs and then only be able to open local
files.)

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

This seem like a totally backwards implementation. You're enforcing a
weird non-native dependency on dbus for windows. A better approach would
be to have a platform independent api for notification (possibly in
Gtk). This api would then have a unix implementation, and a win32
implementation. There is no reason at all for the win32 implementation
to use dbus. If there is no exposed win32 apis for doing notification
the best approach would imho be to implement those using win32 native
APIs (i.e. DCE/COM/OLE, not depending on dbus at all).
 
> > 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.

Its likely possible to implement the specific case of screensaver
inhibition using libXtest (but I don't know the specifics, maybe it
sucks). However, whether the implementation uses dbus or libXtest should
in *no* way affect whether the API is in gtk+ or not, or wheter it
should be pawned off to a separate library.

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

Still, android runs dbus-daemon:
http://benno.id.au/blog/2007/11/13/android-under-the-hood

Its probably used for the kind of things dbus was designed for (easy
async message passing, signals, lifecycle management, process
activation) whereas Binder is used in the implementation of their custom
vm.

Also, I'm not sure where you're going with this? How is the existance of
multiple IPC mechanisms at all interesting when discussing APIs for Gtk?
If dbus is the "de facto" standard way to do something on the linux
desktop then we need to use it for that. If some different system (like
android) use something else, then they need to implement that. Just like
they would need to modify Gtk+ to use their view system instead of X11.

> 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?

I said light, not highly performant. These are not the same thing. By
light I mean doesn't use a lot of memory, doesn't make other things
slow. DBus is obviously not made for pumping lots of data, nor for lots
of low-latency method calls, but thats not really a problem for the
things dbus is normally used for. For instance, gvfs doesn't use dbus
for sending actual file contents, as that would be far too slow (since
these can be gigs of data). Its however an excellent way to manage a
herd of mount daemons, keeping track of them as they come and go, etc.

That said, I wouldn't mind some performance work in libdbus.

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

I hope its obvious that I disagree.