<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> On 30.12.2013 04:55, Lennart Poettering wrote: <blockquote cite="mid:20131230035516.GB30202@tango.0pointer.de" type="cite"> <pre wrap="">On Mon, 30.12.13 03:15, Alp Toker (<a class="moz-txt-link-abbreviated" href="mailto:alp@nuanti.com">alp@nuanti.com</a>) wrote: </pre> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Glad that you're ready to start talking about this. I guess the question I really want to ask is perhaps the elephant in the room. With a different serialization format, a different name registration scheme, different connection parameters, different service description files... heck, some of the fields seem arbitrarily inverted. This doesn't seem like DBus at all, but something entirely different, more "DBus inspired" rather than something related to DBus itself. </pre> </blockquote> <pre wrap="">Nope. We provide quite complete compatibility, there are only very few exceptions visible to app programmers. </pre> </blockquote> <pre wrap=""> Speaking now as an outsider myself, I think Ted was making an observation about the wire protocol rather than developer APIs. </pre> </blockquote> <pre wrap=""> Yeah, we provide the same AF_UNIX protocol as before, under the same socket path, for compatibility. Of course, it won't take benefit of all the fancy new kdbus features, but it's compatibility, nothing else after all. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">One is the different policy language use for the system bus, but even for that we provide full compatbility if people connect via the good old AF_UNIX protocol. </pre> </blockquote> <pre wrap=""> Perhaps a word diff against the standard D-Bus protocol definition will help allay concerns like Ted's, and make sure the various D-Bus libraries adopt any tweaks to remain compatible. </pre> </blockquote> <pre wrap=""> This describes the GVariant-based encoding we use on kdbus currently: <a class="moz-txt-link-freetext" href="http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/GVARIANT-SERIALIZATION">http://cgit.freedesktop.org/systemd/systemd/plain/src/libsystemd-bus/GVARIANT-SERIALIZATION</a> Other than that, have a look the the gvariant docs regarding its serialization: <a class="moz-txt-link-freetext" href="https://people.gnome.org/~desrt/gvariant-serialisation.pdf">https://people.gnome.org/~desrt/gvariant-serialisation.pdf</a> I am certainly not going to wdiff this against the bus spec for you... Note that in the dbus spec we should not document this anyway, but simply refer to glib's/ryan's spec for the marshalling. </pre> <blockquote type="cite"> <pre wrap="">If I can connect with AF_UNIX and communicate the same way on the wire, then it's still D-Bus and I really don't see the problem here. </pre> </blockquote> <pre wrap=""> Yes you can, it's compatbile with that.</pre> </blockquote> Two questions: <ul> <li>Why did you chose to use a GVariant encoding and not sticking to the standardized and established dbus encoding? What were the pro and what were the cons arguments for that (surprising) decision? </li> <li>Also, I was surprised to learn that (among other things) using GVariant one must not transfer strings that contain nul bytes (0x00) byte (cf. section 2.4.5 Strings in the above mentioned pdf)? Why is that? </li> </ul> ---rony </body> </html>