Introduction to D-BUS

[Jeroen T. Vermeulen]

On Tue, August 29, 2006 23:55, Thiago Macieira 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.

So even if there are multiple methods of the same name in an interface,
one of them is still the "canonical" one?


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

Then the binding is part of what the specification calls the
"implementation," right?


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

I'm assuming that "correct" here is not necessarily the same as
"canonical"...  So could I say that "well-defined interface introspection"
is, in effect, an optional layer of specification for what bindings can
and cannot do?


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

And must all bindings be able to handle them in that case, and dispatch
them to a listening program on their end?


Jeroen