D-Bus API design guidelines

D-Bus has just gained some upstream guidelines on how to write APIs which best use its features and follow its conventions. Hopefully they draw together all the best practices from the various articles which have been published about writing D-Bus APIs in the past. If anybody has suggestions, criticism or feedback about them, or ideas for extra guidelines to include, please get in touch!

One thought on “D-Bus API design guidelines

  1. Alexander Larsson

    I don't agree with versioning everything. All those "1" suffixes makes for hard to read code, and not having then in no way makes it impossible to later rev the interface. And in practice a majority of interfaces do not need reving.

Comments are closed.