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