Main Page D-Bus

From NDesk

Jump to: navigation, search


[edit] Thoughts from FOSDEM 07

I (Alp Toker, managed D-Bus) had the opportunity to discuss ideas with Michael Meeks (CORBA, Bonobo hacker), Simon McVittie (dbus-python), Robert McQueen (Collabora Ltd.)... (TODO: add others here)... These ideas came about in various conversations, but don't necessarily represent what was actually discussed (noisy venue, different terminology/language backgrounds) etc.

[edit] Robustness Principle: "Be liberal in what you accept, and conservative in what you send":

This was in relation not to the wire protocol (which should always be dealt with strictly), but with object mapping bindings etc. specifically structs (and complete messages). If additional arguments are appended to the signature, maybe we should simply discard them rather than rejecting the message. This could provide an elegant (but liberal) solution to D-Bus API versioning issues and forward compatibility.


  • If no error is reported, developers won't feel compelled to support issues -- but this seems to be a moot point.

[edit] D-Bus Introspection API:

Start to formalize introspection with a real standardized API to supersede XML introspection? The new API should be at its basis round-trippable to and from the legacy introspection system, and should be used only when needed so as not to break the D-Bus conceptual model.

Main argument in favour of this:

  • Applications are doing this anyway, and they're doing it in non-standard ways eg:
  • bindings that introspect before any calls in dynamic languages
  • Telepathy's "Properties" interface ties in with
  • Lack of uptake of unpopular org.freedesktop.DBus.Properties interface
  • XML does not belong in the core of a binary IPC system -- the D-Bus recursive type system already provides the functionality we need, avoiding XML library dependencies, overhead etc.
  • Addendum: (HAL API has similar issues, also a recent thread on the compiz list suggests the same problems)

[edit] Signatures:

Is there value in creating convention that a Signature argument should represent a single complete type?

Argument against:

  • This goes against precedent in the header of every D-Bus message where a Signature contains multiple complete types.

Arguments for:

  • The protocol already mandates a single complete type for variant signatures but does not formalize the distinction. This appears to be a violation of D-Bus' own philosophy.
  • Would (in common cases) permit an automatic GType/System.Type to/from Signature mapping, obviating the need to expose a custom Signature type in high level bindings (see Telepathy "Properties" interface for a use case)
  • (This is a more abstract argument, and not yet part of this proposal or considered a good idea) An "ag" array of Signatures in the header instead of "g" would simplify argN match rule parsing in the daemon, potentially making negative matches (the common case) faster.

[edit] org.freedesktop.DBus.Local:

Mixed feelings on this one but as we looked at the use case it looked more and more like a libdbus specific concept than an elegant pattern to be followed by other implementations/supported by bindings. TODO: Add reasoning here.

Retrieved from ""