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