[dot] The Big Kolab Kontact Interview - Part I

[Dot Stories]

URL: http://dot.kde.org/1106909457/

From: Fabrice Mous <fabricemous at kde.nl>
Dept: controlling-your-information-flow
Date: Friday 28/Jan/2005, @11:50

The Big Kolab Kontact Interview - Part I
========================================

   KDE Dot News recently spoke with some prominent people from the
Kontact [http://www.kontact.org/] and Kolab [http://www.kontact.org/]
projects. We talked about how both projects got started and how they
have evolved. Enjoy the first part of this two-part interview.



     First of all can you explain who you are and what is your role in 
the Kolab/Kontact project?

     Tobias Koenig: My name is Tobias Koenig, I have been doing KDE
development for 5 years and since 3 years ago I've been the maintainer
of KAddressBook.
 [http://www.kaddressbook.org/]
     Cornelius Schumacher: My name is Cornelius Schumacher. I started my
KDE career by contributing  to KOrganizer and I have maintained it now
for something like five years. At aKademy
[http://conference2004.kde.org/] I passed on KOrganizer maintainership
to Reinhold Kainhofer. I also do various other things for KDE, one of
them is trying to take care of kdepim generally.

     Steffen Hansen: My name is Steffen Hansen, I work for Klarävdalens
Datakonsult AB [http://www.klaralvdalens-datakonsult.se/] and have been
on the KDE project more or less since the beginning. I am the lead
developer of the Kolab server.
 [http://www.kolab.org/]
     Bernhard Reiter:  I am a managing director of Intevation GmbH,
which is a Free Software company. For Intevation I coordinated the
Kroupware and Proko2 contracts.

     What are Kolab and Kontact, and how do they relate to each other?

     Steffen Hansen: Kolab is a Free software groupware solution. The
components are the Kolab server and Kontact, which is the KDE Kolab
client. There is also a Kolab web client in the works.

     Tobias Koenig: Kontact is part of KDE and integrates the main KDE
PIM applications (KMail, KOrganizer, KAddressBook, KNotes) into one GUI.
So it has the appearance of MS Outlook/Evolution but  the advantage that
all components can still run as standalone applications. Kontact
supports access to various groupware servers and one of them is the
Kolab server.

     Bernhard Reiter: Kolab consists of several components:

    * Kolab Solution Architecture
    * Kolab Server implementation
    * Kolab Client implementations (especially the KDE Kolab Client)

     So I would say the current Kontact can act as KDE Kolab Client.

     How did the Kolab project start?

     Tobias Koenig: Martin Konold, a KDE developer, gave a talk on
LinuxTag 2002  in Karlsruhe, which described a groupware solution built
upon Open Source Software that can be used as replacement for
Outlook/Exchange.

     Bernhard Reiter: I have to comment on Tobias here. The Kolab Server
 was not designed to replace MS Exchange. We addressed this question in
our Kroupware FAQ :
 [http://kroupware.kolab.org/faq/faq.html#General3]
     "So no, it's not a goal to build a replacement for Exchange or
Outlook. On the software side we have assembled a solution that solves
some typical asynchronous groupware tasks like group calendaring. Our
usage of standards like disconnected IMAP and the iCalender format is a
new, innovative approach."

     What exactly does a Kolab server do? Because sharing folders on 
IMAP is not a new concept.

     Steffen Hansen: Correct! The server uses well-known and available
free software components like OpenLDAP, Postfix, Apache and Cyrus IMAP
server plus some custom code to glue it all together.

     The features you get from the Kolab server in addition to just
using the individual components (mail, web, imap,...) are:

     a) Central configuration. The tweakable configuration parameters,
user database and so on are stored in one central place: The LDAP
database. Centralised administration of the Kolab server is done through
a web-based interface.

     b) Multilocation support. Because of a) it is possible to set up
multiple Kolab servers that share configuration and user database. It
works by the use of LDAP replication. I see this as a very nice feature
for both supporting multiple weakly connected locations and for being
able to scale up to multiple servers to support huge numbers of users.

     c) Groupware specific functionality. The Kolab server contains code
that does automatic appointment handling for group and resource accounts
on the server. It also creates and manages freebusy lists for all
accounts.

     I heard about Kroupware and Proko2. What's with the names? How do
these  projects relate to each other?

     Tobias Koenig: The first project was called 'Kroupware',  it
consisted of Kolab1 and a KDE client, which was mainly a modified
KOrganizer with embedded KMail.

     Steffen Hansen: 'Proko2' (which stands for "Project for Kolab2") 
had a main focus of enhancing usability of the client and adding
features to the server to allow groups of people to collaborate, do
server based virus scanning, the  multilocation feature and so on.

     Bernhard Reiter:The names refer to two contracts to deliver a
groupware solution. Our companies did this with Free Software and
started Kolab. Kolab is a Free Software project and thus has potentially
 different players and goals than what the contracts might say,  so we
needed to come up with names to decouple this  and being able to openly
talk about it. For example we did not want to overpower the  naming of
the client done by the KDE community.

     How many companies are involved with the Kolab project? I see the
names  Klarävdalens Datakonsult AB, Erfrakon PartG and Intevation GmbH
passing by.  Can you eleborate a bit on your cooperation?

     Steffen Hansen: These three companies combined their efforts to
create a crossplatform groupware solution. But we need to mention a few
others as well:

     Radley Network Technologies is a South African company that make a 
plugin called Toltec Connector [http://www.toltec.co.za/] for Microsoft
Outlook. It allows Outlook  to use IMAP for mail and groupware data.
Radley's has put a big effort  in adding the Kolab-specific features to
the Toltec Connector to allow  it to interoperate with the Kolab server
and other Kolab clients. Among  other things, this includes support for
reading and writing the XML  format that Kolab clients use for internal
storage of groupware data.  Communication between clients is done with
iCal/vCard.

     A fifth company also deserves mention here: CodeFusion
[http://www.codefusion.co.za/]. Like Radley's,  they are also based in
South Africa. CodeFusion offers professional  Kolab support, they have
helped out with implementing some  server-features and they also work on
the web client.

     Microsoft Outlook uses the legacy TNEF format which is not capable
of working properly with iCal. How did you guys find a solution for
that?

     Steffen Hansen: Well, let's first make a distinction between the
format used for communication and the format used for storage. Both
Kolab1 and 2 do indeed use standard iCal for inter-client communication
(ie. sending invitations etc.). Kolab1 also used iCal as the storage
format to store your calendar etc. on the imap server. Unfortunately is
has not been possible to create a solution that allows Kontact and
Microsoft Outlook to share the same storage based on iCal. iCal is too
flexible in some respects and not flexible enough in others. Therefore
Kolab2 uses an easy to read/write and well documented XML format for the
internal storage.

     Creating our own format has been frowned upon by some, but I really
think that it has been a big help for us to have our own format that we
could tailor to our specific needs to be able to make both the KDE
client and Outlook 'happy'. For the end user, the visible result of
using this new format is that he/she can switch back and forth between
Outlook, Kontact and the web client without having to import and export
data between them.

     Citadel/UX, a BBS system claims to be Kolab1 compatible
[http://www.citadel.org/kolab.php]  these days. Does this mean we can
use Kolab compatible clients like Kontact with Citadel?

     Bernhard Reiter: As far as I remember they are not fully compatible
with Kolab1 because  free/busy handling, directory server architecure
and lack of legacy support make it slightly different. Apart from that
you probably can use it with Kolab1 clients.

     Cornelius Schumacher: Citadel/UX is quite interesting because it
has a  long history and is a mature server system. There once was a KDE
client [http://www.shadowcom.net/Software/infusion/history.html] for it
which used KOrganizer as the calendar component. I would love to see
some more interaction between the Kontact and the Citadel/UX developers.

     One problem we have with groupware servers is that there are no
really  accepted standards for them. There are several drafts for
standards and  quasi standards set by implementations, but there is no
generally  accepted standard for access to groupware servers. It would
be great if  we could work into the direction of something like a common
way to  access groupware servers. We did make some very small steps but
there is  still a long way to go. I expect that this will become more
important in  the future as the current situation isn't really
beneficial for  anyone.

     Kolab stores mail folders using the Cyrus "maildir" format. Citadel
stores  everything in Berkeley DB. It seems you are using IMAP to access
files on  the server, which uses the filesystem and returns you that
file. Tell  me.. why didn't you use a database engine for this like
Citadel/UX does?

     Steffen Hansen: We strongly believe that you need a storage
mechanism that fits the problem to be able to scale up. Mail messages
are variable sized independent pieces of data stored in a tree-like
folder structure. This looks a lot like a filesystem to me. For an
example, look at the statistics for Carnegie Mellon
[http://graphs.andrew.cmu.edu/cgi-bin/hammer/mail-stats.pl] (the home of
cyrus imapd):

     I seriously doubt that you can scale that high with a
database-based solution.

     Using mail messages for storing calendar information might seem odd
at first, but it is actually quite nifty. Having one calendar entry per
mail makes it easy to merge data when you have manipulated your calendar
from several places. Also, conflict detection/resolution can be done
nicely with this approach.

     A lot of people complain about the installation procedure of Kolab.
Has  the situation improved? What made it such a pain to install anyway?
Was  it because of the OpenPKG [http://www.openpkg.org/] format?

     Tobias Koenig: For Kolab1 the installation procedure was really a
pain but this has been improved in newer versions. Kolab2 Server is
installable by simply executing one shell script. The reason was not the
OpenPGK format, it's used for Kolab2 as well and has a lot  of
advantages. I guess the main reason was the limited time frame and the
developers didn't put much resources into implementing an installer but
tried to get a stable Kolab version finished.

     Steffen Hansen: Now the server installation has been streamlined a
lot. After fetching the install script, all you need to do is this:
 ./obmtool kolab [wait while it builds and installs]
/kolab/etc/kolab/kolab_bootstrap -b [follow on screen instructions for
initial setup] /kolab/bin/openpkg rc all start [now the Kolab server is
running. You can go to the  webgui and create users and so on]
     Will Kolab in the near future be able to integrate more with an
enterprise  authentication system for single-sign-on? (for example
OpenLDAP, Samba with LDAP support and maybe  if you have
Kerberos/Heimdal set up as well).

     Steffen Hansen: I can not make any promises, but this is something
that has been on our own wishlist for some time.

     Will Kolab have a mailman interface one day? Any plans for that?

     Tobias Koenig: It's not planned yet. Nevertheless it's possible
from the technical point of view, so volunteers
[https://mail.kde.org/mailman/listinfo/kde-pim] are already welcome :)

     People on the MS Windows platform can use the Kolab server through
the use of the Toltec connector. What would be a compelling reason to
use Kolab  instead of let's say MS Exchange?

     Steffen Hansen: Using a Kolab server instead of MS Exchange buys
you better scalability, higher reliability and a soft migration path
away from proprietary software on the desktop (because you can gradually
introduce Kontact and it will share data with Outlook).

     Tobias Koenig: Kolab is fast! Kolab2 will have the same
functionality as  Exchange, and it's Free Software.

     Another very interesting topic is the cooperation with the Free
Software  project KDE. How did that work out? How were decisions being
made with regard to  implementations?

     Tobias Koenig: The cooperation went quite well, most of the staff
from the  company group come from the Open Source community, so you can
talk and work with them like with  every other Open Source developer.
There were also three meetings
[http://pim.kde.org/development/meetings.php], organized by Intevation
GmbH,  where KDE-PIM developers and people from Klarävdalens Datakonsult
AB attend to discuss the  further steps for integrating Kolab support
into the official KDE release. Some evidence of the  success of these
meetings is that KDE 3.3 was released with full Kolab2 support.

     Cornelius Schumacher: I'm speaking from the KDE perspective and
have to say that it was an  interesting challenge. I really appreciate
that the Kolab project  explicitely includes integration of the client
code into KDE  development. In practice there have been some problems
because the  Kolab people actually didn't have enough time to do this
integration in  a smooth way, but in the end, I think, we can be happy
that the Kolab  client has finally arrived in KDE.

     It's a general problem of how to handle integration of third-party
code  into KDE as there are a couple of different interests which have
to be  balanced. Commercial contributors usually produce a lot of code
which  might be hard to properly review for Free Software maintainers
doing  this job in their spare time and which is developed with a
different  goal in mind from the code coming from inside of the project.
The most  important point is to talk with each other as early and as
much as  possible. There have been a couple of personal meetings between
Kolab  and KDE people and they have shown to be extremely valuable.