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

[Havoc Pennington]

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. I don't think it's useful. The signal connection
stuff in the current setup is intended to be entirely in the bindings.

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.

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

Havoc