Starting the kdbus discussions

[Lennart Poettering]

On Mon, 30.12.13 07:00, Alp Toker (alp at nuanti.com) wrote:

> 
> 
> On 30/12/2013 03:55, Lennart Poettering wrote:
> >I am certainly not going to wdiff this against the bus spec for
> >you...
> 
> OK. You were the one who asked for a discussion and review...

I don't think it makes sense to wdiff the gvariant spec against the dbus
spec. 

Regarding gvariant marshalling I am proposing that the dbus spec should
simply refer to Ryan's gvariant spec instead of duplicating its
contents.

> Have you thought about how you'll align this with the reference
> implementation and specification on FDO?

Basically, I'd like to see most of the bits I put together in that
overview included in the spec, however excluding the bits that are not
necessary for interoperability of apps and are specific to our userspace
implementation in systemd. 

Note that the unit file definiton for systemd is something that should
not be documented in the dbus spec hence. i.e. the old dbus service
activation files in my eyes should become more of an
implementation-specific detail instead of standardized. This isn't
unlike the XML policy which isn't standardized in the spec either. The
reasoning for this is primarily that I believe starting processes is
inherently something that should be left to the init system. Since
people cannot agree on one implementation for init systems, I don't
think we should try to tape over that by enforcing a service file format
in the spec.

> You mentioned splitting out the serialization format. Are you
> considering describing the wire protocol as a strict subset of of
> the serialization format going forward, or do you want to give the
> current spec a break and make a fresh start based on your current
> work?

No, this is deliberately kept very very close to old dbus1. Basically
we reuse the old fixed dbus1 message header with all its fields and
flags. However instead of then attached data in the old dbus1
marshalling we use gvariant instead. Basically this is the most minimal
adpotion of GVariant one could think of.

gvariant is very similar in its look and feel to the old dbus1
marshalling, i.e. the signature strings for them are pretty much
identical (gvariant is slightly more powerful though), however the
actual byte image differs.

So, the dbus spec should be updated to simply say that an alternative
marshalling is possible, via gvariant, that should be indicated by
message version 2 in the message header. And that details and
specifications for that marshalling is found in the gvariant spec. And
that some transports might enforce usage of gvariant, while others
enforce classic dbus1 marshalling.

Note that so far we simply said that kdbus always requires gvariant
marshalling (making this strict is political choice, that Ryan asked us
to make), and that classic AF_UNIX transports require dbus1
marshalling. We could extend good old AF_UNIX/AF_INET transports to
support both marshallings, and then negotiate that during connectoin
setup. However, I have not bothered with this, and I kinda like it if we
keep only dbus1 marshalling for that, since this keeps us honest with
our compatibility with dbus1 marshalling, since this means we will still
have a lot of uses (and thus testing) of dbus1 marshalling even on
legacy-free system: as soon as somebody uses dbus across the network it
will use dbus1 marshalling. And given that we use dbus across the
network pretty extensively in systemd (to make systemctl -H work), that
should stay tested.

Also, note that gvariant marshalling for use in dbus is not a new idea,
there have been patches flying around earlier. Also, the dbus spec
already contains preparetion for this as all the extensions that
gvariant made to the signature strings are already documented there with
hints for future expansion. We are simply fullfilling the promise the
dbus spec hence already made...

Lennart

-- 
Lennart Poettering, Red Hat