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

[Havoc Pennington]

On Tue, 2004-08-10 at 06:07, Olivier Andrieu wrote:
> 
> Actually, it also dispatches replies and errors if there is no
> PendingCall to catch them.
> 

Yeah, pretty wrong.

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

IIRC because multiple bindings may be used in an app, and they have to
agree on what object instance is at each object path.

Even if there were shared implementation among bindings for the signal
connections, it would not involve the object tree I don't think, it
would look more like the stuff in dbus-gproxy.c 

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

I can imagine sharing the signal stuff between the bindings I guess, but
it would not look like the object tree. At least it doesn't make much
sense to me that way.

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

There isn't really a good API for method calls, just the basic
message-passing stuff, and the stuff so everyone can coordinate who owns
which part of the object namespace.

Havoc