Dbus Vs NML

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.

http://www.freedesktop.org/Software/dbus http://www.linuxjournal.com/article/7744

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.

another article

> 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.

Portability

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 7964 . 2136 ./dbus 1164 ./test 900 ./test/data 760 ./bus 544 ./test/data/sha-1 528 ./mono 476 ./doc 328 ./glib 248 ./mono/doc 220 ./mono/doc/en 172 ./python 164 ./tools 132 ./gcj 120 ./test/glib 112 ./mono/doc/en/DBus?.DBusType? 96 ./mono/doc/en/DBus? 96 ./gcj/org 92 ./qt etc. "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.