Introduction to D-BUS

[Thiago Macieira]

Jeroen T. Vermeulen wrote:
>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?

Yes. However, a proper interface introspection will list the canonical 
argument types. Whether the binding will accept other arguments or not is 
purely up to the binding.

When I said the method call is delivered if (service, object path, 
interface, method name, parameter type list) matches, I should have 
mentioned that the parameter type list can match anything.

Also another caveat: the interface name may be empty and it'll still 
match.

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

Yep, that's the empty interface name. The binding is required to deliver 
the call if it can, but it can reject if it's ambiguous (or it could 
deliver arbitrarily to one interface, if there's such a difference).

For example, in the Qt binding, an ambiguous call will deliver 
arbitrarily. In Java, from what I understand, there can be no such thing 
because the call will never be ambiguous: if you have two ambiguous 
interfaces, then they are the same function.

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

If you're using a well-defined interface introspection and you expect 
interoperability, you follow rules like these:
* The callee MUST accept the correct parameter types.
* The callee MUST return the correct parameter types.
* If the input parameter types don't match, the callee MUST either reject 
with an error or convert them (kinda obvious, but...)

The caller MUST use the correct parameter types. Using of wrong types 
results in undefined behaviour.

Signals may also be overloaded (nothing in the spec or the library 
prevents them from being so), but for semantic purposes, they should 
share some commonality. I'd say that all overloads of the same signal 
should be emitted at the same time, since they probably contain different 
aspects of the same information.

But the same applies: 
* Signals MUST be emitted with the correct parameter types.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/dbus/attachments/20060829/682e2659/attachment.pgp