Introduction to D-BUS

[Jeroen T. Vermeulen]

On Wed, August 30, 2006 01:06, Thiago Macieira wrote:

> No, I meant methods with the same name across interfaces. Overloading of
> methods with the same name in the same object (whether in the same
> interface or not) is not interoperable.

Hmm...  Maybe this "interoperable" should be a key term in my text then. 
I could describe just the interoperable features in the mainline text, and
add sidenotes on what is technically possible beyond that.

Alternatively I could describe things in layers but I think that would
make it harder to get from first principles to a working knowledge of the
model.


> Nothing of this sort is stated in the specification. This is just my
> thinking of how implementations intending to be interoperable should
> work.

So is it time for an update of the spec, maybe?  I'm entirely new here so
I may be missing any number of things, but the impression I get is that a
lot of experience with the existing spec has accumulated here that the
spec could benefit from--whether functionally or just as a document. 
Things like this: what a binding can expect and should handle from clients
that may not be fully interopable, and what it should do in order to be
interoperable itself.


>>And must all bindings be able to handle them in that case, and dispatch
>>them to a listening program on their end?
>
> That's a good question. We know that overloading of argument lists can
> cause some interoperability problems for method calls. I don't know about
> signals. The difference here is that you ask to listen to a specific
> signal, so the implementations may be able to filter the incoming
> messages to what they want.

I guess they'd have to...  AFAICS you ask to listen to a specific signal
*name* (can you omit the interface name there as well BTW?) but if there
are multiple with the same name, is there currently any way of selecting
exactly which one you want?

Fully reliable and complete information on what signals the object or
interface can emit is not generally available, from what I've heard so
far, because of concurrency issues and the dynamic nature of object types.
 So the binding would have to compare each incoming signal to the
signature of the client's handler for the signal.


> The Qt binding is capable of listening to any signal as long as one part
> of the identification (service, object path, interface, signal name,
> argument signature) isn't a wildcard, except for the argument signature.

"Wildcard?"  I haven't come across that term.  It's mentioned once in the
spec, but I can't really make sense of what it says there.

Oh BTW, there's a broken link in the spec, earlier in that same paragraph.


Jeroen