KDE Dot News recently spoke with some prominent people from the Kontact and Kolab 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.
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 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 and
have been on the KDE project more or less since the beginning. I am
the lead developer of the Kolab server.
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:
"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 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. 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
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 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 (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 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 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, 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.
Comments
if you want to implement, lets say, a pluging for it in your own enterprice you have to pay to Troll Tech for the developers tools, and that's at least $1,500
They won't have to pay. If you use the plugin only in your company, you don't have to realease the code. Read the GPL.
A somewhat unknown part of the Mormon religion is that the universe is a modeled after what we know as a solar system... in essence the entire universe is rotating within a fixed orbit. In the same way that the Sun is the center of our solar system, the universe is rotating around its own massive object. Mormonism theology suggests this object is an ULTRA massive planet that is so large is would cause the entire universe to rotate around it. The name of this massive planet is Colab.
initially I would have thought of the name as something coincidental, but the Colab logo causes me to think otherwise.
Are there Mormon influences within the Colab project?
kolab was founded mostly by germans in germany, and I don't (think) there are very many mormans in germany, so I doubt it. Interesting information though.
"Are there Mormon influences within the Colab project?"
The project's name is Kolab, not Colab
The client name is Kontact, not Contact.
I might have misspelled the name. I just remember someone telling me... never seeing it spelled.
Back in college, I had to Mormon missionaries that lived across from me at apartment that told me the info.
I should have typed Kolab to make my text relevant.
I'm sure the name probably comes from "collaboration" seeing as it's a groupware solution. I'm no definitive source though, ask the developers :p
If you are mormon, then yes.
If you are not, then no.
Issue solved.
:)
But most of this was done in germany, which is heavy luthern, no?
I created the current version of the Kolab logo (modelled after a previous existing one for the kolab project). AFAIK neither the original author nor me (pretty sure about the latter ;-) are Mormons. And the name is just a short form for collaboration.
Still it's a nice story (although as a physicist I'd like to point out that you don't really need the hypothesis of a massive central body just to make the remaining universe rotate around a common center ;-) .
But of course everyone needs Kolab! :-)
On another note, I would like to say that the logo is totally awesome! It looks extremely professional and fresh.
Great work, Torsten!
The exact Mormon name is 'Kolab'. Not Colab. You can see this referenced by their mountain and canyons in Southern Utah -- Kolab Canyon. Google it.
Btw, mormons suck.
Although I am now a follower of Christ, I am a former Mormon who attained the Melchezidek priesthood, therefore I can speak from personal experience. I can tell you that Mormons believe and teach that Jesus originally came from the planet Kolab, which is somewhere in the universe. They may deny this, but they also believe that Jesus and Lucifer were brothers created by God the Father. They teach that God the Father told Jesus and Lucifer to come up with a plan for the salvation of mankind, that God the Father preferred Jesus' plan of sacrificing Himself over Lucifers plan to force mankind to obey God. That, supposedly, was the beginning of Lucifer's jealous rebellion against God. They also believe that those who are worthy will become gods themselves and create their own worlds just as Jesus did. Their real focus is not on Jesus, but on Joseph Smith as a prophet of God. In reality, because they believe that Jesus was created, they deny His deity as part of the Triune God, which, by definition qualifies Mormonism as a cult. Mormonism is truly one of the more cleverly devised deceptions of Satan. I know a great deal about Mormonism and am willing to answer any questions about it.
I feel bad for you. You are not correct and missed the mark many times in your text.
Are you ready?
Either the Kolab server is not using Cyrus-IMAP, or the interviewer and developers are not talking about the same thing.
Cyrus-IMAP uses several different database formats for message storage. It does *NOT* use Maildir for message storage.
Courier-IMAP uses the Maildir format, but it does not scale into the thousands of users, or the tens of thousands of messages per folder. Trust me, I've tried.
I have 500 MB of archived mail, with several folders with 15,000+ messages in them. Trying to get this to work on a dual-AthlonMP 2200+ system with 2 GB of RAM was not a lot of fun using Courier-IMAP and Maildir. It would take upwards of 30 seconds to load a message index, and it could take even longer to do operations on multiple messages.
I installed Cyrus-IMAP on this same server, copied my messages over from one setup to the other (using Kontact no less), and haven't had any problems since. Folder indexing and access is in the sub 5 second range on my largest folders (just under 20,000 messages to date), and doing operations on multiple messages takes no time at all.
So, are the Kolab poeple using Courier-IMAP and Maildir, or are they using Cyrus-IMAP and database storage for messages????
I believe that the interviewer means that Cyrus IMAP stores messages as files in the filesystem -- just like MailDir.
But you are right that Cyrus does not use MailDir. It uses it's own storage format which is basically this: One file per message, filename is the IMAP UID of the message. In addition to that, metadata/indexes/etc are stored in small binary databases (skiplists, berkeley dbs etc...). The important issue here is that the message contents is not put one big blob somewhere.
Aha. That makes sense.
FYI: My company has all email stored on a Pentium III - 550 MHz, 256 MB RAM Kolab 2 server using an encrypted filesystem on a venerable 3Ware based RAID-1.
My personal email alone is 4773 MB spread across 580.000 messages.
Sofar the performance of Kolab2 or Kontact is not an issue at all!
Reading the article it is really hard to understand what Kolab actually is. It basically comes down to
- Kolab server, which is just Cyrus and some other components already available on every
regular Linux distribution
- Kolab Client, which is just Kontact and available for a lot of servers, including Exchange,
Groupwise or OpenGroupware
What do I need Kolab for?
One can get the kernel source from kernel.org, the sources of the GNU system from gnu.org, the KDE sources from kde.org, yet most Linux users use one of the available distributions.
Kolab offers a lot of extra features including multi-location support and server side freebusy generation and server side resource management (rooms, car fleet....)
Actually, the emerging standard looks like it's going to be GroupDAV (http://www.groupdav.org), an HTTP-based protocol designed for open source groupware clients to talk to open source groupware servers. On the client side, KOrganizer and Evolution are both going to support it (very soon), and there is talk about eventually getting Thunderbird/Sunbird speaking GroupDAV as well. On the server side, both the Citadel and OGo servers will offer GroupDAV support in upcoming versions. I would strongly suggest that the Kolab developers get on this bandwagon as well -- as I've said elsewhere before, I really think the Kolab2 protocol is the wrong direction to go in.
Anyone looking for a good open source groupware system, please do check out Citadel [ http://www.citadel.org ] -- it is a very complete, flexible system and it is VERY easy to install.
Bynari (www.bynari.net) has the solution. Their Web based groupware and Outlook connectors also use both TNEF and iCal natively.
Using the Binary connector to access a Kolab 1 server didn't convice me. The Toltec connector did by far a better job.
I can second this experience very much.
For Kolab1 we initially relied upon the Bynari connector. In the meantime I am very happy that alternatives did develop.
The Toltec connector is a very nice product. Unfortunately as of today the Toltec connector for Kolab 2 is not publicly available. (I expect it in the next weeks though).
I like to run server software on freebsd for linux, os/x and win clients ...
Can I do
cd /usr/ports/net/kollab ; make install
to get it running? Kollab (the server) seems to have no LDE specific components?
This would truly rock!! I think openpkg is basically RPM ... there is an "rpmtopkg" script out there somewhere the rest would be getting all the bits to build on FreeBSD using the ports MAKEFILE infrastructure.
http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019928.html
Most of the pieces already build on FreeBSD? e.g. OpenLDAP postfix CyrusIMAP Apache ProFTPd SASL etc. let's wrap it up!!
The ports MAKEFILE stuff will be easy to port to OSXServer, NetBSD, OpenBSD, and DragonFly ... :-)
Check out http://wiki.kolab.org/index.php/Kolab2_linux_distribution_integration
for an exmaple to see what needs to be done to port kolab...
Actually FreeBSD (no support for jail currently) is a common and supported platform for Kolab 2.
All you need to do to get the Kolab 2 server running on FreeBSD is:
- get all packages from http://max.kde.org:8080/mirrors/ftp.kolab.org/server/beta/kolab-server-2...
- become user root
- run sh -x ./obmtool kolab
- run /kolab/etc/kolab/kolab_bootstrap -b
The rest is configured via the webinterface https://yourserver/admin/
Sorry forgot to mention that before login into the web admin gui the Kolab server must be started of course:
/kolab/bin/openpkg rc all start
If OpenPKG would be fine for everyone... Is the kolab wiki patch list up to date?
Yes, it is uptodate and we are in the process of providing the patches upstream
did this ever go anywhere?
I am very interested in using Kolab, but the openpkg method of double installing everything that probably already installed on our FreeBSD server is not very attractive.
Did anyone make progress in creating a FreeBSD port for the Kolab server using patches on the standard port packages or cyrus, postfix etc...?
The double install in unavoidable when install Kolab. But, there is an upside to how they install things:
All (for the most part) of Kolab's necessary programs are contained in one directory: /kolab. The programs there are statically linked to one another and will not interact with programs out side of its directory. (at least this is how I understand that it functions).
So, I guess the one of the things to consider when installing Kolab is whether or not dedicating a whole server to its functionality balances against your needs. Otherwise, I find it absolutely worth it.
Kolab server can not be installed the way you explain it in /Kolab because it doesn't respect the layout of the FreeBSD's filesystems. man 7 hier
*BSD are usualy cleaned system: they don't install double system/server just because the author of a software think that it is a good idea to pack a lot of other project available on the net with his/her project.
The only good reason I think to install a copy of something already available in the ports tree and outside the usuale $PATH is if your software (kolab) is running with specialy patched version of imap and smtp server (or something else) that is not available in the ports tree.
Hi,
I was expecting to see at least few words related to Aethera (http://www.thekompany.com/projects/aethera/) because IMHO it helps both Kolab and Kontact projects (see my comments below).
Kolab has only *one* client which is available *now* for all the most important platforms (Linux, Mac OSX and Win) and this is Aethera. It looks they are not very interested in promoting it.
More, Aethera has support for shared folders for Kolab *and* Citadel, it's the only client which can do it for both groupware servers now.
Aethera is open source and it's using a changed version of KOrganizer. I am sure that my effort to port KOrganizer to Mac and Win will help KDE PIM to get Kontact ported to those platform too (especially the current effort to synchronise the sources with latest KOrganizer). I am sure that both Aethera and Kontact have something to get looking each other for bad and good points.
Thanks,
Eug
Aethera looks real nice, and have actually been on my "recommend for windows users" list for some time:-) So keep up the good work.
As for promoting, have you tried to get it included on TheOpenCD, http://theopencd.sunsite.dk/. As of 2.0 they only have a mailclient (Thunderbird) and not a real PIM application.
> have you tried to get it included on TheOpenCD, http://theopencd.sunsite.dk/
I think they won't allow a program that uses the QT library in the OpenCD, since the windows version is not libre.
> It looks they are not very interested in promoting it.
Who is "they" referring to.
Aethera's Kolab support is mentioned on both Aethera's and Kolab's website.
Yes, 'they' means the Kolab project team.
The Aethera description from Kolab website is poor (nothing about OSX).
There is an old comment that Win version has problems which looks like 'please don't try' etc.
There are more comments but it's not the place to talk about.
Please provide a patch to the website with uptodate information about Aethera.
Actually I am very happy about Aethera as the mere existance of many Kolab clients proves that the Kolab concept is pragmatic.
Lastly I have to admit that the Kolab website is far from optimal. Help is definetly appreciated.
There is a german Company named "Konsec" (www.konsec.com) that has a Product similar to the Toltec Connector. I downloaded a Public beta and it seemed to work fine. Has anyone tried it in combination with the KDE Kontact?
Is there any posibility to get an kolab2 setup from the beginning till the end?
Becouse i have bin trying to do that for two days and I still havent done anything.
I'm afraid posting a comment to a two month old news article won't get you much attention from people who have the knowledge to answer your question (I don't, sorry). I would try the kolab homepage http://www.kolab.org/. There are links to documentation, to a support forum and to the mailing lists.