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

[David Zeuthen]

On Sun, 2004-08-08 at 22:35 -0400, Havoc Pennington wrote:
> 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?
> 

Not really, because how would you specify what service and interface you
want signals from? I suppose that it would be good to state in the docs
that dbus_connection_register_object_path() is only to be used for
handling methods on the callers own objects. 

To handle signals, would it be useful to have similar functions,
dbus_connection_register_signal_handler(svc, interface, path), such as
to avoid creating a message filter? Though it probably would require
some tricky code to minimize the traffic between the bus and peer.

> 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 wouldn't really make sense to set them both at the same time, would
it? (you can invoke messages without having a path, and signals are sent
to pretty much all parties who have asked the bus for them). So, won't
the type field in the header (METHOD_CALL or SIGNAL) specify the
semantics of the existing DBUS_HEADER_FIELD_PATH?

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

If you allow the public to use it then sooner or later some message
filter is going to steal messages from another message filter in the
same process. dbus_bus_get_dedicated() is one attempt to avoid that.
Implementing register_signal_handler and making add_filter() private is
another.

Cheers,
David