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

[Havoc Pennington]

On Sun, 2004-08-08 at 13:35, David Zeuthen wrote:
> On Sun, 2004-08-08 at 19:26 +0200, Olivier Andrieu wrote:
> >  David Zeuthen [Sun, 08 Aug 2004]:
> >  > >  > 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?
> >  > > 
> >  > > Absolutely.
> >  > > 
> >  > 
> >  > I beg to differ :-). Sometimes you want to listen to all signals
> >  > regardless of the object path and this is currently only possible
> >  > with _add_filter() if I'm not mistaken.
> > 
> > You can register a fallback handler for "/". That should catch signals
> > from any object.
> > 
> 
> OK, thanks, I didn't think of that, my bad. I'll change my code to use
> these functions instead of _add_filter(). The documentation for
> _add_filter() should state that non D-BUS code shouldn't use it though.

Wait, I think the fact that signals *from* /foo/bar go to the object at
/foo/bar is completely accidental ;-) Does that even make sense?

Maybe we need to break apart DBUS_HEADER_FIELD_PATH into
DBUS_HEADER_FIELD_SENDER_PATH and DBUS_HEADER_FIELD_DESTINATION_PATH, it
seems I was confused or something. Maybe I'm just tired right now and
forgetting what I was thinking.

It's not that add_filter() is supposed to be private or something, it's
just supposed to be low level. Yes, there's a problem here that there's
no plain C (without GLib) API that's high level.

Havoc