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

[Kay Sievers]

On Sun, 2004-08-08 at 12:23 +0200, David Zeuthen wrote:
> On Sat, 2004-08-07 at 23:19 -0400, Havoc Pennington wrote:
> > On Sat, 2004-08-07 at 21:09, David Zeuthen wrote:
> > > 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.
> > > 
> > 
> > If all the signal handlers return NOT_YET_HANDLED, does it solve the
> > problem?
> > 
> 
> That would solve that particular problem, yes, but it also introduces
> another problem: libbar no longer has control over what signals it asked
> for. In a way, that implies double bookkeeping. 
> 
> An example: libhal provides an interface that says ''tell me when
> properties for this device object change'' and an application programmer
> might want to do this when he sees a device object he likes. This could
> be the ethernet adapter that is being used as the default connection
> (e.g default route) and he is interested in the signal that says ''link
> status has changed''. Now, another instance of libhal in the process
> have requested to get all properties changes on all device objects and
> there is the problem. 
> 
> Without dbus_bus_get_dedicated() libhal, or the application author,
> would have to keep track of the signals requested in order to continue
> to provide this API.
> 
> > Maybe the root issue is that for a method call, you want only one
> > handler, but for a signal, you probably want all the handlers to run.
> > That might be the better place to fix the problem... hmm.
> 
> I'm not sure, it's difficult for me to articulate, but wanting to push
> all signals to all handlers is somewhat similar to problem we have with
> UNIX signals and libraries, e.g. you can't, as a library, really rely on
> handling UNIX signals in transparent way to the process using you. Of
> course the problem isn't that bad, since adding a filter doesn't remove
> the other filters like with signal(2).
> 
> It just seems wrong to me that a library, like libhal, always have to
> assume the DBusConnection is shared. Are there any problems,
> architectural or otherwise, with the concept of get_dedicated(), other
> than resource consumption and bloat of course, that I'm not seeing? 

Isn't the dbus_connection_add_filter() more a global filter for incoming
messages of a connection, than a filter for specific messages delivered
to the D-BUS users? More intended to _intercept_ the general message
handling in D-BUS?

libhal uses this global filter mechanism to dispatch the signals to the
registered HAL user functions. Can't libhal (or other libraries too)
just use dbus_connection_register_object_path() to get called at
incoming messages for the objects paths it is intersted in? This would
be the "real" filter. The message would be dispatched by D-BUS itself
and libhal receives only the messages it is authoritative for and can
return the DBUS_HANDLER_RESULT_HANDLED flag for this connection.

Kay