Re: Merging gio into glib



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



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