Re: Merging gio into glib

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-11-07 at 14:55 -0500, Havoc Pennington wrote:

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

Its kinda similar. libgio does have an implementation for local files
only, so you can use libgio with no extras and its just a fancy way to
do local file i/o (well, it also has things like cancellable async i/o
on local files, etc). However, it also has a module system such that if
gvfs is installed apps using the gio api automatically, and with no
changes needed will now also support non-file: uris. 

> Answers I can imagine or that you've already said:
>   - a single .so allows GSettings interface to use GIO interface,
>     or vice versa

Even in the two .so case one could use the other I guess. However, if
both use each other things go sorta bonkers.

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

One nasty way I could see this working is the dbus binding lib being
part of glib (don't puke now) but glib itself not linking to dbus.
Instead the actual call to g_main_context_integrate_dbus_connection()
would be a macro (or inline function) that expands into code that passes
in all the values for the symbols needed from dbus (i.e. i would pass in
the address of dbus_connection_set_watch_functions, etc).

glib would need dbus as a build requirement for this to work (needs the
dbus types), and the glib header for the function would have to be
separate (with a separate .pc file for it) so that it can include
dbus.h, but it would work, and avoid an extra library. And if you squint
and ignore the implementation details it would be quite easy to use.
Just link to glib and dbus, then call the function.