Here it is, the page you've all been waiting for.
Comparing DBUS and NML
is like comparing apples and oranges.
DBUS is a messaging layer library. NML is an implementation of both a language and a messaging layer.
Gee it looks like this situation is hardly new or unique -
A discussion on the KDE list about DBUS:
- "throwing away a working, proven, stable and cross-platform IPC mechanism (as DCOP is) and breaking backwards compatibility completely just because there is some new kid on the block and it's trendy, THAT is ludicrous."
- It's not just because there is a new kid on the block. It's very important for KDE to interoperate with other toolkits. Because DCOP depends on X11 ICE it means you can't easily have a native Mac OS X version for instance, whereas with a sockets based ipc mechanism that's no problem.
- "If DBUS proves to have all the functionality, the reliability, performance and cross-platform abilities"
- I see no reason why it won't. It seems to me that it has been carefully engineered not to be over-engineered, and to be compatible with DCOP.
- "yes, we run KDE on Solaris here and there aren't any Linux kernel events on that system"
- Well the whole idea of the system D-BUS is to raise the level of abstraction to not depend on things like kernel events. If someone inserts a CD in the disk drive, the D-BUS signal should be the same on Solaris as Linux even though the origination of the event might differ.
Cross platform yadda yadda
- Tor Lillqvist was recently hired into the Novell Desktop group. Tor is the primary mover for the port of Gimp and the Gtk+ toolkit to Windows. According to at Novell, Tor will continue to work on Gtk+ and "various parts of the Linux desktop stack on Windows to improve the experience for cross-platform developers." That's exciting! He is currently working on a dbus port to help complete Fredrik Hedberg's port of Beagle for desktop search to Windows.
- > Speaking specifically of D-BUS, Jon looked into porting it to Windows
- > and spoke to Havoc about the idea already. He learned that D-BUS already
- > has a fairly well-abstracted system layer and porting it to a new
- > operating system is essentially a matter of writing one file.
- Those who use Fedora (and I"m sure other distros do this too) have D-BUS setup already. I know my install of CUPS uses D-BUS, and there"s talk of D-BUS support being bundled along with the kernel. D-BUS doesn"t really need anything, even glib.
DBUS additional perks:
it is well documented
it has a large number of active developers who are supportive of other develeopers who need help learning how to use DBUS
there is a large movement underway to provide DBUS as a standard component of many desktop linux distros
How big is DBus?
1447582 Jun 14 05:11 dbus-0.33.tar.gz
tar -zxvf dbus*; cd dbus*; du | sort -nr
"about 25,000 lines of code for the client library, and 2,500 lines of code for the bus daemon"
Of course this doesn't mean that all of that code will be loaded into memory.
DBus notable features
The D-BUS debug transport is a specialized transport that works in-process. This means that a client and server that exists in the same process can talk to eachother without using a socket.
Sigh. I'm really not awake enough or motivated enough to write this right now.