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

[Olivier Andrieu]

 David Zeuthen [Mon, 09 Aug 2004]:
 > 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? 

with match rules and by testing these fields in the message
handler. That's not different from the way it is done with filters.

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

Yeah but the current implementation will happily send non-method calls
messages to the function registered with register_object_path, so
beware. 

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

Yes, _register_object_path and _register_signal_handler would both use
the same object tree dispatch mechanism with the difference that
_register_signal_handler would add match rule so as to receive the
signal and we could enforce the _register_objec_path only handles
method calls and _register_signal_handler only signals. 

I'll make a patch.

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

That's how I see things.

-- 
   Olivier