hal_initialize() overrides other filter/object/fallback
functions on separate connection
Havoc Pennington
hp at redhat.com
Sun Aug 8 19:35:18 PDT 2004
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
More information about the dbus
mailing list