Starting the kdbus discussions

[Lennart Poettering]

On Fri, 03.01.14 13:18, Simon McVittie (simon.mcvittie at collabora.co.uk) wrote:

> > So they
> > already are systemd unit files, and they just continue to be, its just a
> > bit more mandatory.
> 
> That seems an odd statement. Being more mandatory is like being a bit
> less thread-safe, or a bit more pregnant. :-)

That was meant a bit ironically...

> Being "conditionally mandatory" - existing things will continue to work,
> but you can't take advantage of $NEW_THING unless you write a systemd
> unit file first - is fine.

Yes, that's the approach here.

> > As you can see: the first 16 bytes are 100% identical between dbus1 and
> > gvariant messages. Only beyond that the gvariant marshalling results in
> > different serialization.
> 
> This seems perverse: if the header is compatible but the content isn't,
> then the message is not compatible, and as a result, there's no value in
> the header being compatible.
> 
> I'd be happy to reserve a "message major version"[1], or a message flag,
> for you to use to represent "this message is in GVariant-style
> serialization, not the serialization described in the D-Bus Specification".

Well, the header already has a field for indinicating the "protocol
version", which we make use of here. dbus1 messages have protocol
version 1, gvariant messages have protocol version 2. 

I see quite some benefit in keeping the other header fields identical
too, since with this scheme you can determine the size of a dbus message
from it regardless if the payload is encoded in dbus1 marshalling or
gvariant marshalling. 

This is not immediately useful admittedly, simply because so far we
strictly said that gvariant marshalling is the only accepted thing on
kdbus, and dbus1 marshalling is the only accepted thing on
sockets. However, the latter is something we might want to open up a
bit, so that both marshallings can be spoken via sockets (subject to
negotiation of course), and even on the same conection (which might be
useful for some dbus-daemon implementations or for some direct
connection users to make the remarshalling unnecessary we currently do
for everything in our kdbus proxy service...

So yupp, I kinda like the uniformity here....

> > Well, the spec exists precisely to minimize these differences and to
> > allow multiple implementations while staying compatible.
> 
> Spec patches that describe GVariant serialization are welcome.
> Until/unless merged, it isn't spec'd.
> 
> If the normative description of GVariant serialization is not itself
> part of the D-Bus Specification, and the D-Bus spec just says "see this
> other document" that's OK, but in that case I would like the "other
> document" to be at least as formal as the D-Bus Specification itself: so
> something with version-numbered releases, a changelog, and a stable,
> non-vendor-specific URL that doesn't point to someone's personal
> public_html or similar.
> 
> I'd prefer it to live in either dbus.git, glib.git or systemd.git, and
> be uploaded to freedesktop.org (or maybe gnome.org in its role as "home
> of GLib").

Yeah, it would be good if Ryan would add this tothe glib docs
maybe. Ryan?

> > I somehow have the suspicion here though that kdbus is more
> > interesting to most people than classic dbus1 pretty soon, so excuse
> > my arrogance here, but good luck with that.
> 
> I'm happy to review stuff for integration into dbus and into the D-Bus
> Specification (time allocation permitting), but please do not present it
> as a fait accompli. If I see design or implementation flaws, I'm going
> to point them out, and the onus is on the patch submitter to either
> justify the design ("yes we know that's not ideal, but the alternatives
> are all worse, and here is why") or fix it.

TO make this clear: we specifically didn't post a patch to the the spec
here, because this all is not a done deal yet. We want the input first,
before we turn this into a patch for the spec.

Thanks for the thorough review! Much appreciated!

Lennart

-- 
Lennart Poettering, Red Hat