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

[Olivier Andrieu]

 Havoc Pennington [Mon, 09 Aug 2004]:
 > On Mon, 2004-08-09 at 18:31, Olivier Andrieu wrote:
 > >  > 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.
 > 
 > It's really totally accidental that the object path registration
 > stuff dispatches signals.

Actually, it also dispatches replies and errors if there is no
PendingCall to catch them.

 > I don't think it's useful. The signal connection stuff in the
 > current setup is intended to be entirely in the bindings.

But what's the reason for having the method calls dispatch in libdbus
and the signal dispatch in bindings ? It's about the same thing:
dispatching incoming messages to application code ! 

 > I think the right fix is to simply only dispatch method calls via
 > the object path tree.
 > 
 > >  > 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 don't think this is useful. It belongs in the bindings, as things
 > are currently architected.

I don't understand this. The whole object dispatch stuff should go in
the bindings then: it is not needed for the bus implementation and it
can be implement as a special filter function. It could altogether be
moved outside of lidbus. 

But I don't think that's a good idea to have every binding
re-implement this object-tree dispatch mechanism since it is
non-trivial. That would probably introduce bugs or different
behaviours between bindings. Same arguments apply for signal handling:
it is not completely straightforward to implement because it has to
handle match rules and maybe service tracking.

Besides, since DBUS is meant to convey events from the kernel via the
system bus, I find it bizarre to say that it's not useful to have an
API for signal handling when we have one for method calls.

 > >  > 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.
 > 
 > It's certainly possible to overload PATH to be both SENDER_PATH and
 > DESTINATION_PATH, yes. However, it's confusing. As demonstrated by
 > this inadvertent "feature" that the object tree could be used for
 > signal dispatch.

Unless I'm mistaken, libdbus and the bus daemon pay no heed to the
PATH header (except for match rules and policy checking): it's only
used when dispatching messages in the object tree. It's just
additional data for the special object dispatch mechanism so that it
can locate the message handler. If we have _register_signal_handler
and _register_object_path it's no more confusing I think. 

-- 
   Olivier