JSON for introspection

Simon McVittie smcv at collabora.com
Thu Feb 7 12:55:55 UTC 2019


On Thu, 07 Feb 2019 at 06:33:06 -0500, Felipe Gasper wrote:
> I’m just looking for a lighter way to describe introspection than XML. CBOR, Sereal, etc.

Remember that D-Bus is designed to be interoperable between multiple
implementations.

If we introduce a new introspection format, then for the foreseeable
future, every library that generates introspection (GDBus, QtDBus,
dbus-python, etc.) has to know how to generate both, in case it's
being accessed by a tool that only knows the old XML form; and every
tool that consumes introspection (gdbus introspect, d-feet,
dbus-python, etc.) has to know how to parse both, in case it's being
used to debug a service that only knows the old XML form.

If we were to move to any new introspection format, it would be one
that is defined in terms of the D-Bus type system, as proposed in
<https://gitlab.freedesktop.org/dbus/dbus/issues/158>. There's no
point in using a different text or binary serialization like JSON or
CBOR when D-Bus already has its own binary serialization format (the
"wire format" used for D-Bus messages) that needs to be understood by
every D-Bus client and service already. However, it would need to have
really compelling advantages for anyone to invest much time in this.

Introspection is designed to be used by debugging and code-generation
tools, rather than for production use at runtime. Because it can't
describe semantics, only syntax, it is always necessary to know the
semantics (meaning) of a D-Bus method before you can call it successfully;
and if you know those, then you also know the right types to use.

(dbus-python does use introspection at runtime, but I consider that to be
a historical design flaw: it gives dbus-python really weird error behaviour
whenever the types derived from introspection don't match the types the
client-side programmer expected.)

On the service side, it's easy to generate basic introspection XML
without an XML library: interoperable D-Bus method/signal/etc. names
don't include any <>&" characters, and any reasonable service can trust
its own code to be non-malicious, so it's usually a simple matter of using
printf. For example, the reference dbus-daemon generates its introspection
XML at runtime, on-demand, without using an XML library, from the same
"vtables" that it uses to dispatch method calls to C code. GDBus has a
similar design.

On the client side, introspection XML doesn't do anything fancy (no DTDs,
no CDATA, no namespaces), so if you trust the sender it's easy to parse
with a simple non-standards-compliant XML-subset parser like GLib's
GMarkup. If you do want to use a fully-featured XML parser, Expat is
small, permissively-licensed and nearly ubiquitous, and libxml2 is
another good choice.

The reference dbus-daemon depends on Expat, but this is for its XML
configuration files (which are specific to the dbus implementation and
not part of the D-Bus specification), not for introspection.

    smcv


More information about the dbus mailing list