Why KDE: Components, Components, Components

I was out having a pint with a fellow when he mentioned he uses (and quite likes) Evolution as his email client. He had a few gripes about it, but then don't we all when it comes to the software we use day-in and day-out? He then mentioned how he was surprised at just how huge a program it was. i asked if he knew how many lines of code went into Evolution, and he guess about right. I then asked him if he could guess how much had gone into Kontact; he though a little less than Evolution, but probably a similar amount. This is, however, far from the truth. Kontact is dramatically smaller that Evolution in terms of code count, even when taking into consideration all the various apps that are associated with it (KMail, KOrganizer, KAddressbook, libkabc, the various kioslaves). Then he asked a very interesting question: if I wanted to make a KDE mail app that was an alternative to KMail, would I be able to, would the KDE project encourage such an effort, and how much work would it be?

I smiled, sloshed back a swig of frothy brew and started to explain how KDE apps such as KMail were put together. For networking there are ioslaves, which get things such as SSL and TLS support nearly for free. These ioslaves are easily reusable via the KIO framework. His theoretical email application would only need to pass URLs and fill buffers with messages when requested to send email, and do similarly (if in the reverse direction) to receive emails. Without writing a single bit of code to specifically speak the RFC protocols, his app could send via SMTP and ASMTP with or without SSL or TLS and receive emails via POP3 and IMAP (again with similar SSL/TLS support). This means his KDE mail app would only need to provide local storage of email (assuming it wasn't pure IMAP) and a user interface that had a folder browser, reader and composer. The KDE addressbook library grants a ready-made contacts solution, and sprinkle in some configuration dialogs using the new KConfig Xt and you've got a mail app. Configuring toolbars, opening/saving files, customizing keyboard shortcuts and more are very nicely wrapped by classes that grant you that functionality in a few lines of code each.

But this doesn't just mean faster development. It also means that when a bug is fixed or an optimization committed by the KMail developers in the IMAP implementation (for example), his mail app would also receive that fix. And vice versa.

It also means that since KMail and my friend's new mail app would both rely on the same basic components, they would also stand a much better chance of interoperating properly. They could share account settings and address books, for example, and basic UI elements orthogonal to email usage (e.g. toolbars and their configuration) would be similar in each.

This solid use of components is a great boon to the developer. But it's also a boon to the user. Why? Well, by empowering the developer, KDE provides a better chance the user will get what they want. Applications with similar scopes can be developed with as little duplication in effort as possible, and custom development can harness the work of those that went before (even if they went in a slightly different direction).

Other platforms have promised or are promising highly componentized environments. KDE actually delivers that today.