Starting the kdbus discussions

[Simon McVittie]

On 30/12/13 03:50, Lennart Poettering 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. :-)

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.

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

[1] you know, the one next to the endianness, which is hard-coded to 1
    in current D-Bus

> Ryan is doing the porting work for gdbus, and the Samsung guys are doing
> the porting work for libdbus1. With that in place, we have support from
> all three libs.

Regarding libdbus and the D-Bus Specification: "freedesktop.org bug, or
it didn't happen".

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

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

Thanks,
    S