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

[Kay Sievers]

On Mon, 2004-08-09 at 21:01 +0200, David Zeuthen wrote:
> On Mon, 2004-08-09 at 20:47 +0200, Kay Sievers wrote:
> > > > 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. 
> > 
> > Hmm, I get _all_ signals from the objects I subscribe to. I've added a 
> > register_object to the python bindings and get all signals sent from
> > /org/freedesktop/Hal/Manager. This works for me:
> > 
> > dbus.py:class Bus
> >   def add_object_match(self, handler_function, path):
> >         match_rule = "type='signal',path='%s'" % (path)
> >         dbus_bindings.bus_add_match(self._connection, match_rule)
> >         self._connection.register_object_path(path, None,handler_function)
> > 
> > DeviceManager.py:__init__
> >         self.bus.add_object_match(self.gdl_changed,
> >                                   "/org/freedesktop/Hal/Manager")
> > 
> 
> Yah, that's the current behaviour. However, I think that the point was
> whether it was actually smart to mixup the namespace for objects you
> export yourself (which you have exported through register_object_path)
> with the signals you're interested in receiving.

It's only registered in the local instance of libdbus and depends
to the actual connection. There is no knowledge about it outside
of the registering process. It is just used to dispatch the incoming
messages to the subscribers, or I'm wrong?

Kay