hal_initialize() overrides other filter/object/fallback functions on separate connection

[David Zeuthen]

Hi,

On Sat, 2004-08-07 at 20:24 -0400, Havoc Pennington wrote:
> Hi,
> 
> Sorry to reply after you wrote a patch ;-)
> 
> A couple things here:
> 
>  1. DBusConnection has state, yes, but nothing that afaik should 
>     cause one user of the connection to interfere with another.
>     As long as the simple rule of ignoring a message that isn't
>     interesting to you gets followed.
> 
>  2. Remember that filter functions are supposed to be a freakish
>     thing you don't usually use, just like Xlib filter functions.
>     libdbus is a low-level library meant to use in *implementing* 
>     higher-level APIs.
>

But the low-level libdbus library needs to be used by (low-level)
libraries, wrapping D-BUS calls, that wants to remain free of
dependencies on GObject, Qt, Python or other higher-level APIs. 

In the short term, at least until the higher-level APIs are complete,
we'll need to do it this way since I guess that everyone agrees that
libdbus is too low level to use in desktop applications. 

It's still an open question to me whether the higher-level APIs will be
sufficiently easy to use such that we don't need to write wrapper
libraries for D-BUS services at all. That will probably depend on the D-
BUS service (need for client-side caching etc.)

>
> That said, with some more careful explanation maybe get_dedicated() is
> useful, but I'm not convinced yet.
> 

Heh, I'll give it a shot; I think it's quite useful, practical even, for
libraries that wants to hide the implementation detail that they are in
fact providing their service through a centralised daemon using D-BUS.
Surely, hal is an example of this (libhal being the library), and I bet
that most system-level D-BUS services would like to do this.

One situation where it's useful is when you have a single process that
has components that each use such a wrapper library, e.g.

         FooDaemon
         |      |
      dlopens   dlopens
       |           |
 FooComponent1   FooComponent2 -uses- libbar
     |
    uses
     |                  
   libbar

FooDaemon is a session-level daemon. FooComponent1 and FooComponent2 are
not aware of each per se, they may be contributed extensions to
FooDaemon. libbar speaks to the BarService using D-BUS. FooDaemon
doesn't use D-BUS, but it does provide a mainloop that libdbus can
integrate with.

Specifically, the BarService emits signals on certain objects. libbar
may choose, at the discretion of the user of a libbar instance, to
listen for all signals on all objects, but if there is only one
DBusConnection only one of the libbar instances gets the signal. Which
is a problem. Having libbar use dbus_bus_get_dedicated() solves this
problem.

This sounds far fetched but try replacing FooDaemon with GNOME VFS
Daemon, libbar with libhal, FooComponent1 and FooComponent2 with GNOME
VFS module handlers and the signal with 'new USB device added' and
you'll see my motivation for writing the patch :-)

> A possible other way to do this is to have an address passed to
> dbus_connection_open() that refers to a bus, e.g. instead of
> unix:path=/tmp/foo maybe bus:type=system - this would not do any
> communication/registration with the bus though, or maintain a global bus
> connection, it would just open a connection and encapsulate the way to
> find the bus address. (Env variable, etc.)
> 

That could work as well, it just seems a bit backwards to me.

Cheers,
David