posted by Dennis Heuer on Mon 28th Nov 2005 16:31 UTC

"D-BUS, 2/2"

Discussing a service network is not an easy task. For example, multimedia frameworks obviously must implement more than one service to expose their capabilities over D-BUS (a simple player-service, a mixer-service, a filter-service, etc.). To generate an advantage for the clients, just serving the established interfaces is not enough. The frameworks would have to assimilate into one generalized multimedia resource on the D-BUS network. Only a well-discussed D-BUS framework can guide this process successfully.

Not only backends generate resources. For example, I use totem with gstreamer for playing audio but xine-player for watching digital tv. Sometimes I would like to have both running in parallel (one in standby-mode). In those cases I wished I had a mixer application that displays faders for the running media applications instead of for the audio channels. But how can such a mixer application ever instruct multiple (possibly unknown) media-players if they wait at individually chosen D-BUS addresses and provide individual interfaces? Should instead all media-players support this (one of possibly many) mixer application(s)?

The above shows that the implementation of a message bus alone can not guarantee any advantage over the current situation. It may even worsen it. Keeping the problem at the service or the client-side is not a solution either. This is why I want to discuss a mediating D-BUS framework at this place in the hope that it is interesting and useful to developers in general.

The question is: How shall independently developed services and clients find and work with each other if the network is open and the services are not part of a lock-in strategy like in the proprietary world? The only answer I know is that general service daemons must mediate between the clients and the services. These daemons have well-known addresses; and they focus on only one specific subject. This implies that a service daemon of this type is not developed to expose a full media framework to the network. Its intend is as simple and easy to grasp as its name (players, recorders, mixers, alerts, ...).

A service daemon is mainly a small manager that provides a generalized interface to be used by both the supportive framework and the potential client. The interface is reduced to the job-dependent semantics. It communicates only event-dependent changes of attribute values. The object that provides the relevant attributes is implemented in the service daemon. For example, the mixer daemon implements an object that is used to remember the D-BUS address, the current state, and some other necessary values to control a single fader on the D-BUS network. The object is maintained in an object array (the resource list).

Both client and service can send events to the daemon. An event can target at one or multiple registered objects and attributes. Typical events are new, read, write, or signal. The service daemon manages an alert service (event handler) to inform about changes (like when a service sends a delete event to unregister an object). That's it, mainly. The most important aspects are the specialization of the daemon and the well-discussed interface. It should be a very simple interface, best is similar if not identical in most parts to the interfaces of the other service daemons. At least the codebase should be reusable.

There are lots of aspects not discussed here. For example, service daemons must manage concurrent services in a sane way. At least some informative flags (like UN/STABLE, BACKEND_NAME, and BACKEND_VERSION) must be gathered. A service daemon should always run locally to be detectable without having to know the host. Service daemons of the same type may bridge hosts to share resources. Service daemons should be runtime-configurable. Daemons may map other daemons to provide service-bundles (profiles).

The idea has not fully settled down yet. However, I've invited the people to read the article because I think that some semantic network is necessary if free platforms shall survive the next generation of proprietary paradigms.

About the author:
Dennis Heuer is a social scientist and specialized in system theory. His professional focus is on the use of ICT in education and development. Privately, he is developing a new environment targeting at non-governmental and educational institutions to provide a real-time (live) platform for communication, education, simulation, and easy prototyping.
Table of contents
  1. "D-BUS, 1/2"
  2. "D-BUS, 2/2"
e p (0)    22 Comment(s)

Technology White Papers

See More