Introduction to D-BUS

[Jeroen T. Vermeulen]

On Tue, August 29, 2006 22:25, Matthew Johnson wrote:

>> But this bit is all about D-Bus typing.  Does it hold true for D-Bus
>> objects/interfaces/methods?
>
> I was just pointing out that there is no reason that an object should
> not gain or lose interfaces throughout its lifetime.

Ah, OK.  That answers my question exactly--just wanted to be sure.

Can interfaces on a particular object also gain or lose methods during
their lifetimes?


> When I get a method call I lookup the object in a table. If it exists I
> look at the parameters that I have received and their types. I then
> lookup methods on that object with that name and type signature. Java
> can reflect at runtime on the type signatures of methods and dynamically
> invoke the correct one.

Understanding is dawning, I think: matching method invocations to method
implementations is also a pure binding issue, so bindings can choose to do
argument matching or not, right?

What got me off on the wrong foot here, I think, is reading (in the spec
IIRC) that D-Bus implementations were allowed to reject ambiguous method
invocations when no interface was specified.  There was no mention of
ambiguous invocations within a single interface, and I reckoned that if
the "implementation" was the daemon plus library, and they were allowed to
make method resolution its business...

Oh, while we're on this: won't there be any problems when calling a method
built on an overloading-capable binding from a program built on a
non-overloading binding?  Could the invocation succeed but return
unexpected output parameters, for instance?  Or what if signals are
overloaded?


Jeroen