Re: Merging gio into glib

[Havoc Pennington <hp redhat com>]

Hi,

It may not be clear to everyone on the list the structure of GIO and 
GSettings; we had a discussion with Ryan about it on Monday. (I am not 
100% sure GIO works the same as GSettings, so I'll talk about GSettings.)

Applications use GSettings, which includes an interface for storing 
preferences, and also defines the schema file format and loads the 
schemas at runtime. However, GSettings does not have a backend that 
actually stores settings.

This is provided by the dconf module, which includes the on-disk data 
format. Apps should never have to use dconf directly, unless they are 
something special like a gconf-editor equivalent.

I think GIO/gvfs are the same, right, where GIO is just interfaces, and 
gvfs provides an implementation? Apps would not link to gvfs directly?

In the settings case, the backends might include dconf (which is a 
dbus/dvalue based thing), a simple GKeyFile type backend, and/or a 
Windows registry backend (used on Windows only of course); presumably 
all of these are still in the separate dconf module and not bundled into 
GLib?

The idea is the same for GIO, right, where gvfs provides the actual 
implementation? Or is there a "simple plain local IO" backend in GLib 
itself?

Would GSettings have the "simple just a file" backend in GLib itself?

Does it really make sense to have things in the GLib tarball if
there's no backend that comes with GLib - why not just put the
interfaces (GIO, GSettings) in the gvfs or dconf packages?

Answers I can imagine or that you've already said:
 - a single .so allows GSettings interface to use GIO interface,
   or vice versa
     (since they are both just interfaces, is this likely?)
 - 1 dso instead of 2 slightly more efficient
 - the plan is to include a simple fallback implementation
   in GLib, though GNOME apps aren't expected to use this

dbus binding lib
===

Another library to consider in the overall plan is a dbus glib binding; 
for the moment we stuck the main loop integration in an additional tiny 
little lib packaged with dbus (yay extra link time!) but in principle 
eventually we'd also have an actual binding library. This binding 
library should (imo) be a dependency of gtk for sure, and would probably 
make sense as a dconf and gvfs dep, though since they are being written 
today before there is a binding library, it's not clear we'd ever bother 
to rewrite.

Anyway, the dbus binding lib is not analogous to GIO/GSettings because 
it does not have this interface/backend split - it would have a hard 
dbus dep right in the API. It would also not be used in the gtk.h 
interface, while GSettings and GIO will be. I guess the dbus binding lib 
is more analogous to dconf and gvfs - which have dbus deps themselves. 
On the other hand, the dbus binding lib is not a dlopen()'d module or 
backend at all, it would just be a plain lib.

Havoc