Short notes for better D-Bus APIs

Posted on July 28, 2010

2


Client/Server architecture

Fairly any non-trivial system consists of more than one process and needs to use IPC. In the most cases there are data-providers and data-consumers. Many people use in that case a broker/server to connect these components.

Such service provides following functions:

Methods

  • Register/Announce
  • Unregister
  • List

Signals

  • Appeared
  • Vanished

However if you look closer, the message bus already provides these functionality via the org.freedesktop.DBus Interface. (Specification)

Instead of calling register(), you own a name like “your.project.dataprovider.specialprovider” via “RequestName()”. List get’s replaced by the D-Bus method “ListNames()” (additionally filter for your prefix, e.g. “your.project”). The signals are also provided by D-Bus through “NameOwnerChanged”. Although every proper D-Bus Binding should hide these functions behind a nice API. So just look into the documentation….

What are the benefits?

  • No need to write and run your own server/broker
  • The list of available components is public. No need for special interfaces.
  • Stateless, any component can appear or vanish without disturbing the others

Properties

As many languages didn’t natively support the concept of properties, it became common to write functions like GetAttribute/SetAttribute and people also adapted that for D-Bus APIs. However there are good news! We have an Interface for properties. (Specification)

What are the benefits?

  • Generic, some bindings also do automatic caching of properties which gives you access to properties without D-Bus calls
  • “GetAll()” reduces the overhead of several independent calls
  • Change notification via the PropertyChanged signal (as far as I know, only implemented by GDBus)

Thanks for your attention!

Advertisements
Posted in: Uncategorized