RFC: DBUS & KDE 4
Havoc Pennington
hp at redhat.com
Sun Oct 3 00:41:54 BST 2004
Hi,
I'm the first to admit dbus is verbose and has a lot of lines, I think
there are several reasons:
- unit tests (70%-plus coverage of basic blocks, quite good)
- docs (all or nearly all public API has inline doxygen)
- virtualization of features such as stream transport,
authentication, etc. (in C, which is verbose)
- handling out of memory (doubles size or more, I think)
- no dependencies (means you have to hand-roll some stuff)
- the "binding glue" to support main loop integration etc.
is much of the libdbus API, the app-programmer API
should be far smaller
C/no-dependencies was just required to get adoption - cf. earlier
complaints in this thread about dependencies - and OOM handling was
required for the systemwide/secure bus. Unit tests and docs are just
sane. Some of the virtualization may turn out to be pointless and we can
change it back to hardcoded.
Also, I just like long function and variable names. ;-) But insert the
old joke about how code runs faster if the variable names are only one
letter...
The size ignoring comments and whitespace is pretty sane:
[hp at localhost dbus]$ grep ';' *.[hc] | wc -l
14711
And that still includes unit tests and so forth.
Havoc
On Wed, 2004-09-29 at 20:16 -0400, Maks Orlovich wrote:
> >
> > FWIW, I don't think it have to be that specific to conclude D-BUS will be
> > well maintained. If we assume the complexity and contribution-threshold of
> > DBUS is similar to DCOP, it is reasonable to conclude it will be at least
> > as well maintained as DCOP.
>
> I one was to replace libICE w/libLYOD (assuming I would finish the server
> bits) I would estimate that DCOP would be around 7000 LoC[1] of C++, server
> included, not counting the IDL tools and the command-line client tool.
> dbus-0.22's dbus/ directory (which does not include the Qt bindings) is
> 30,900 LOC of C, although to be fair that includes quite some unit tests.
>
> So one code base would be more than 3 times larger[2], and written in a coding
> style that's quite different from that of a typical KDE application.
>
>
> [1] With libICE, it'd be 5000 lines of C++, 8000 lines of C.
> [2] To be fair, it's partly because it's using the STL, while D-Bus has its
> own implementation for everything.
More information about the kde-core-devel
mailing list