Re: GVariant for prez!

[Havoc Pennington <hp pobox com>]

Hi,

On Mon, Apr 13, 2009 at 3:00 PM, Ryan Lortie <desrt desrt ca> wrote:
> GVariant has nullable ("maybe") types which were a proposed extension to
> DBus some time ago but never materialised.  iirc, Havoc, you had a
> favourable opinion of this extension but wasn't sure exactly how we'd handle
> the compatibility issues that would come up (also: didn't want to do the
> work yourself, and nobody else stepped up).
...
> About the "protocol version 2" thing, I think we had a discussion about it
> on the dbus list once and it caught some flack but most people ended up
> being more or less OK with the idea, but it came down to nobody willing to
> do the work again.

Right, I think this is accurate. The main danger perhaps is putting a
protocol v2 in glib, and then when we try to integrate into libdbus
finding some reason it needs to become protocol v3. It would certainly
be safer if we had someone to do the libdbus work sooner than later.

Re: protocol v2, I think some of the elements I at least definitely
agree with (maybe-types as an approach to null, for example), though I
don't know what the whole dbus community would think. Other things are
inherently a bit different for dbus vs. generic gvariant (whether to
have size/depth limits, for example). Other things I think maybe have
not been discussed or I don't remember what they are.

Potentially the gvariant format should be documented; the dbus
protocol spec is not a rigorous thing that would get past ISO, but it
is enough that one can more or less reimplement based on the spec, and
read the spec to understand how the protocol works. If we moved dbus
to a protocol v2, we'd need to document that protocol. To propose
moving dbus there, we'd also need to document it. And to enable
maintenance of glib or interoperability with non-glib stuff for
gvariant, we'll need docs.

An approach to the docs that would help for maintaining dbus could be:
document the "v2" serialization format in a separate non-dbus-specific
document, but perhaps reusing as much organization and language from
the dbus spec as possible for ease of comparison. Then edit the
current dbus spec xml so that it describes both v1 and v2, referring
to the v2 "binary serialization format" document for v2 details, and
highlighting the differences between the two protocols. Then we have
one standalone document that describes the v2 format; and the dbus
spec explains both v1 and v2, which will be necessary for implementing
dbus-with-v2-support, and will also catalog the differences for
discussion purposes.

Havoc