Proposing ObjectManager interface

[Simon McVittie]

On Mon, 28 Feb 2011 at 11:10:22 -0500, David Zeuthen wrote:
> Yeah, totally could use a "Best Practices" document... more for app
> writers, not so much to guide bindings authors ...

... where by "app writers" you mean "D-Bus API writers" I assume? (Not always
the same people writing all the implementations, e.g. in Telepathy the D-Bus
API is deliberately implementation-neutral, although we require at least one
client and one service implementation before we undraft anything.)

It'd also be a useful checklist for binding/reimplementation authors, though:
"is your binding a toy or a usable implementation?"

> Should also cover whether adding parameters to methods/signals is an
> ABI break (it's not in C, for example) - I'd argue it's not but most
> my code would probably fail if this happened.

The fact that we have to think about the answer means it isn't in the
interoperable subset, IMO.

I'm not sure what you mean by "it's not [an ABI break] in C". If you mean C
function-calling, adding parameters to a function is only compatible in one
direction - if you upgrade the caller to pass extra parameters before you
upgrade the library, that's explicitly allowed by the standard (although for
non-varargs declarations your compiler will complain, for good reason!), but
if you upgrade the library to expect extra parameters before you upgrade the
caller to pass them, the library will be looking at whatever random crap the
caller has left on the stack and it's unlikely to go well.

In D-Bus, I think we usually want compatibility in both directions: a newer
client should usually be able to cope with an older service (maybe with
impaired functionality and a "this is far too old" cut-off), and a newer
service should definitely be able to cope with an older client (again,
maybe with a "this is far too old" cut-off).

For the record, varying the number of parameters breaks the bindings I'm
familiar with: dbus-glib always, dbus-python almost always, and most real-world
plain-libdbus code that I've looked at (dbus-python and libdbus can
both be used in a lower-level message-passing mode, which would cope, but I
don't count that as part of the object model). I haven't written practical
GDBus code yet, and I can't remember the details of QtDBus right now.

    S