Proposing ObjectManager interface

[David Zeuthen]

Hi,

On Mon, Feb 28, 2011 at 11:59 AM, Simon McVittie
<simon.mcvittie at collabora.co.uk> wrote:
> 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?"

Good point. JFTR, I was specifically thinking "D-Bus API designers"
not "Server-side implementers" or "Client-side library implementers".
While it's always mostly necessary to have business logic on the
client-side, I think it's a desirable goal to have D-Bus APIs where
this is kept to a minimum because it makes it a lot easier to use the
D-Bus API from other languages (such as JS).... So, yeah, my view is
simply that the D-Bus API should be a first-class citizen. Also makes
it a lot easier to learn the D-Bus API using d-feet(1) and gdbus(1).

(An example of where this is not the case is the e-d-s APIs - these
D-Bus APIs basically impossible to use without the client-side
libraries. And turns out the client-side libraries are really bad
(they do blocking IO without letting the user know - sometimes it
blocks until network is up -> login hangs) so for gnome-shell, I ended
up kicking all that code out of process with the shell using a very
simple D-Bus protocol that the shell uses to talk to the
out-of-process helper. Insane, yeah, but what can you do.)

(FWIW, I used to be religious about this... advocating that D-Bus
services like e.g. udisks or upower shouldn't ship client-side D-Bus
libraries. These days my view is a bit more nuanced... just for the
sheer convenience of it (and because command-line tools will need it),
udisks 2.0 will indeed ship a libudisks2.so library that exports a
nice GObject API (that also works well with introspection and D-Bus
properties are GObject properties so things like GBinding and
g_settings_bind() Just Works(tm) out of the box). Now, most of this
API will be auto-generated by gdbus-codegen(1), but certain key parts
of it won't be.)

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

Yeah, should probably consider adding parameters as an ABI break then.
Your point about needing both back- and forward-compat is a good one -
it's usually not something that people care about in non-IPC setups
(which is probably still the most common way of writing apps).
Definitely something to emphasize in guidance documents.

    David