The ICT-Business is known for strategic terms. One of those terms, which was used quite a lot over this year, is services. The term is interpretable; however, the focus was on technical concepts implemented to serve for a sharply rendered use case, like managing user data and authentication. Services in that sense are served over a type of network. Despite the first impression, they are not served to a user but to a calling application. This client utilizes one or more services for internal purposes. Though, the user may be expected to provide data (the password, for example) or to wait and receive a gathered result.
From a distant viewpoint, services in the above sense are developed for technical reasons. They are expected to enhance the sharing of (mainly server or system) resources. Further, they shall control the process of sharing to protect vulnerable resources. Taking a closer look, they shall substitute the old paradigm of an open system with a paradigm of a closed and controlled system. The term services in the above sense also implies locking in customers and positioning on the global ICT-playground that is drifting unstoppable to a fully mobile and networked playground with frequently changing or cross-utilized products, providers, and carriers.
All global players have introduced such lock-in services and will go further in that direction. Here is where D-BUS comes in. D-BUS is a free, lightweight and efficient substitute for aging and/or hard to utilize Inter-Process-Communication solutions like CORBA or COM. D-BUS concentrates on the messaging part; it does not restrict the possible services in any way. The documentation loosely specifies services as callable applications that must follow some technically necessary communication rules (like on Internet). Though this is, at the first look, common for IPC, vendors tend to restrict (if not cut off) this openness by entangling their implementations with the distributed environment, which is settled on multifold protocols and other regulations that reduce the environment to a type of sandbox (At least, the vendors throw lots of working hours at the development. See Eclipse(TM) or the recently illuminated Singularity(TM) project.) It is quite visible that service and contract-based environments, in combination with trusted platforms, are ought to guarantee the future lock-in strategies.
D-BUS is not intended for being strategically entangled with services. However, I fear that this rhetorical difference, in which I find a real advantage over proprietary strategies, will not play out well. D-BUS is very popular in the free-source community; and its lack of dependencies is seen as an advantage. That it does not even settle on a well-discussed service framework seems like a disadvantage to me, though. Without clear terms and rules incompatibilities will come up at every node of the network. There will be multiple concurring services available on a D-BUS network, but a client will not be capable of utilizing just two of them. The open network will only manage virtual lock-ins and feel like the proprietary cousins.
D-BUS draws complexities that can not be mastered without a shift to a well-discussed D-BUS paradigm. The problem is that, up to today, the resources of a computer are discussed in terms of applications and frameworks. Services instead provide individual solutions for the case. To successfully establish a service network (even locally), the network must provide nodes with clearly distinctable and reliable names and addresses (paths). Every such node manages a pool of only one class of services. Services can be combined and updated at runtime. The first pool provides dialogs for every case.
Such a service network differs fully from how today’s environments are designed. This is why I fear that the potential of D-BUS will be left unused. D-BUS will become subordinated to the needs of the applications, which will remain the monolithic frontends they are today and serve virtual lock-ins to selected resources.
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 freedesktop.org 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.
1) No idea how Eclipse is related to DBUS
2) Wouldn’t it be easier if both xine and totem would register with a well known org.gnome.mixer service?
On the otherhand, some kind of store could be needed, both DCOM (registry), CORBA and Internet(DNS) have one (for good reasons).
There could be service org.freedesktop.dns, with a known interface that could answer questions like: “give me all printer spoolers”, etc.
So let’s talk:)
Who said D-BUS was going to provide a services network?
All well and good. But, from the standpoint of getting stuff done, we need to figure out how to integrate a Gnumeric spreadsheet and an Abiword document, possibly querying something in an RDBMS, just because.
DBus sounds like great infrastructure–I’ll follow anything Robert Love is working on based on his reputation alone. But the endpoints are as important as the line connecting them.
What about bonobo of GNOME ?
I think the evidence shows bonobo sucks. It’s a great idea but somehow not too many people seem to be using it. This all becomes clear when you compare it to kparts or kio (sorry if I messed up the names) which just plain rock and work everywhere in KDE, while bonobo doesn’t seem to have that level of ubiquity.
I’m not sure if Kparts being superior (if it actually is) has much to do with it; Nautilus doesn’t use bonobo extensively by design (it’s restricted to file managing, not web browsing, document viewing, etc).
Nautilus no longer uses Bonobo in any fashion. I believe Gedit is looking to remove Bonobo in the next major release.
So, GNOME is moving away from Bonobo and is focusing more on ABI stable shared libraries and in-proc plug-ins.
That’s pretty sad as Bonobo and it’s primary component (Orbit2) started to look pretty decent (in terms of cpu and memory consumption) more or less at the same time Miguel lost interest in it.
Dbus is fine system service transport and notification mechanism but it’s not comparable to BONOBO, which was made to serve different purpose (OLE on linux).
And failed, unfortunately.
I guess it shows a role of good documentation in success of a project (and a framework esp.).
>Nautilus no longer uses Bonobo in any fashion. I believe Gedit is looking to remove Bonobo in the next major release.
Realy ?
$ ldd /usr/bin/nautilus | grep bono
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0x03f20000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0x021b9000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0x0211f000)
$ rpm -qf /usr/bin/nautilus
nautilus-2.12.1-6
Hmmmm… you’re right: there’s still some Bonobo lurking there. I was thinking of the removal of the Nautilus views based on Bonobo (in favor of plug ins). The developers are working on getting Bonobo out, though: http://mail.gnome.org/archives/nautilus-list/2005-October/msg00026….
At any rate, thanks for the correction.
~Andrew
kloczek spake:
>Nautilus no longer uses Bonobo in any fashion. I believe Gedit is looking to remove Bonobo in the next major release.
Realy ?
$ ldd /usr/bin/nautilus | grep bono
libbonoboui-2.so.0 => /usr/lib/libbonoboui-2.so.0 (0x03f20000)
libbonobo-2.so.0 => /usr/lib/libbonobo-2.so.0 (0x021b9000)
libbonobo-activation.so.4 => /usr/lib/libbonobo-activation.so.4 (0x0211f000)
$ rpm -qf /usr/bin/nautilus
nautilus-2.12.1-6
“I’m not sure if Kparts being superior (if it actually is) has much to do with it;”
Kparts uses DCOP and DBUS was inspired by DCOP, that’s why it was mentioned I guess. It would be wonderful if both KDE and GNOME used the same framework for communication between various services, but I don’t know what plans KDE has. I have read some months ago that DBUS and DCOP serve the same purpose, and the latter being more mature and proven, at that time there was no intention to switch to dbus (dbus also was lacking in some areas).
Basically: DBUS intends to be what DCOP is (and was for a few years) for KDE, only it’s a GNOME thing. There is some effort to make it appealing for KDE as well (standardizing on one framework is a nice idea) – but whether or not KDE4 will use dbus or not remains to be seen (again, this depends on many things: whether or not DBUS can catch up with DCOP by then, the difficulty of switching to DBUS, and afterall, it already has the functionality of DBUS in DCOP)
KParts and DCOP are two different techologies.
An application can offer interfaces via DCOP or access other application’s interfaces without needing to work with KParts and vice versa.
No, I believe it’s CORBA that sucks, bonobo is just another implementation of it.
You know that Bonobo is a piece of crap when:
1) it is a Gnome project but Gnome does not use it
2) Gnome devs know it’s crap but right now there’s nothing even remotely functional to replace it
3) it was developed by Miguel De Icaza
You know that Bonobo is a piece of crap when:
…
3) it was developed by Miguel De Icaza
You forgot the rest of that sentence: “and even he doesn’t use it anymore, having moved on to create even better things like Mono to replace it.”
You forgot the rest of that sentence: “and even he doesn’t use it anymore, having moved on to create even better things like Mono to replace it.”
Just one thing on this: Despite his capabilities of presenting himself as the world’s front inventor in the medias, he has only copied whatever he has found useful in the proprietary (MS/MAC) world (NortonCommander, WindowsExplorer, Photoshop, Desktops, Excel, C#, what’s next?) but never invented a single piece on his own. He is overhyped, and his commercial attitude is unhealthy for GNOME.
Even the gnome project is moving AWAY from bonobo, afaik, so I don’t think it’s a good candidate.
I was very shure that somebody will ask what D-BUS has to do with Eclipse, and so on. This is not what the article is about. The article is not about how the projects compare. It is about how they will be used in future. What I wanted to put the finger at is that D-BUS will become dominant for service-like communication on free platforms like linux, and that the quality of this “link” will be compared to the quality of other strategies. This is why I think that D-BUS may not be thought for this but should be prepared for this. There is a project, and there’s reality.
When one of bonobo or kparts becomes an official project at freedesktop.org, there may be a sense in going with it. But, from my point of view, both are too highlevel. D-BUS can do that with an “address-book” (store, as one mentioned). The query should work similar to SQL (though easier and in D-BUS style: just calling the right address and getting an object with results back).
Hello all,
I’m J5, a co-maintainer of D-Bus and release monkey. A few points to correct some of the things I have been seeing in the posts:
1) D-Bus is not a Gnome technology and in fact KDE, XFCE and others can and do use it to some extent. Gnome has just been quicker in adopting it.
2) Qt4 already has excellent bindings for D-Bus, Waldo is working on making it a DCOP replacement. It is up in the are if KDE will fully embrace it or use it along side DCOP.
3) D-Bus is just the lower level messaging facility, it is not comparable to COM or other larger frameworks. Frameworks should be built above it which is what this paper looks like it wants to do.
4) Robert Love did not write D-Bus. He has written other parts of the the stack such as gnome-volume-manager. Please read the AUTHORS file and give credit where credit is due.
To the author: have you checked out the queuing abilities of service names in CVS? It could for instance allow multiple multimedia apps to ask for the o.fd.mixer service which would make one the primary and the others part of the queue. If the primary goes away the next one steps up. You can even program each app to grab the primary when it is focused.
The author:
Haven’t seen the queuing abilities yet. They make me think, though. There is some general misunderstanding here. When you see all the postings about bonobo, com, and so forth, you may agree that the technocrats are just sitting on their worldview that everything is discussable in terms of apps and frameworks. I think that this is the old view. What you write about the queuing abilities has something of this old view too.
It’s not enough to find a resource. And, when you look at my example in the article, a client should be able to access the full queue and determine how to use the registered entities. When all the faders just work how they like it, a client may not be able to use a single one. Another one has brought up the example with abiword and gnumeric. I think that this is already too high-level because the question is not if abiword is searching for a gnumeric table: it is about “client” scanning “clipboard” and detecting a table of type “gnumeric”. Even that is too high-level because: will client be able to work with this table? If you look from the technocrat’s perspective, this is a matter of the both apps. I disagree.
I think it is a matter of sane interfaces. Apps may register themselves as “full services” on the D-BUS network but they should also register their “resources” at other, well-known locations. They should do that like the others do that and provide the same interfaces. I don’t think that this will come up if not somebody specifies a standard with general interfaces per resource-type.
Here lies the problem. Just searching, finding, and using only works if NEITHER (like you wrote) everything can just register any interface everywhere NOR app1 expects app2 on the line BUT only if the client is prepared to talk a standard that is supported by the service too. This is the mediating layer between the both apps. And it must be defined a sane way. Neither D-BUS nor the frameworks solve this a sane way. There will be concurrency and disfunction.
There “must” be some D-BUS framework specification that guides the developers to come together over D-BUS instead of doing only their own stuff (at least if one takes for serious what is happening in the world of ICT).
It’s in draft and certainly in RFC phase. There exists a library that abstracts out the DBus part as well as for servers (players) and clients (e.g. control applets).
It is not directly what you’we discussed in your article, but we are heading towards this direction.
URL is: http://beep-media-player.org/index.php/MPRIS