After a long phase of testing and bugfixing, Kolab, the result of the Kroupware project, has finally been announced. Kolab is a groupware solution that offers email, group calendaring, notes and tasks. Kolab Server is available as 1.0, the KDE Kolab Client is provided in an improved 1.0.1 version. Additionally, the Kolab Server can also be used with Microsoft Outlook™. This makes it an ideal tool for migrations to the GNU/Linux platform.

The KDE Kolab Client is based on well-known KDE components such as KMail, KAddressbook, KOrganizer and KPilot and integrates them. One of the most interesting features is the disconnected IMAP mode, which makes the Kolab Client offline capable. All Kolab Client developments are being merged within KDE CVS and scheduled as new features for KDE 3.2 right along with Kontact, official successor of the KDE Kolab Client.

Yes, we already made Debian client binaries (Some minor testing still required). You may expect them very soon (I think on Tuesday next week or so) on the download site. They are made for Debian Woody and KDE 3.1.1.

Now, although it's Client/Server, the offline portion seems to indicate that your client contact info, etc. is available disconnected. Is it in the KDE contact database, or will there be a new data repository for this information. I.e., how well does it integrate with KDE? Will kpilot work with it out of the box (I'm getting a new PDA on Monday :) )?

The Disconnected IMAP means that it's going on my laptop asap. No more messy mailsync scripts and local imap servers to get everything working. VERY nice.

While I had nothing to do with this, it should be very obvious. Contacts are something that should be shared via server (if user wants), but should also be on the client when offline. Finally, when the clinet reconnects, the client/server should re-sync.
LDAP does not offer a nice way (unless you use replication which requires you to add and maintain a ldap on the client; hard to do on a palm or zaurus ) to handle the sync between server and client, but imap does this by design.
Gotta admit that I think it is strange solution,
but after thinking about it for a bit, it is actually not a bad one.

The more that I think about it, the solution was an excellent choice. They are re-using tried and true code/protocol from OSS world. To go down the LDAP approach would require building quit a bit more code to emulate local storage. Then, there would have to be a redevelopment of the sync on top of LDAP.
This is simply more bugs in the making as well as more code to maintain.
Nice job, folks.

huh? what in IMAP is geared towards disconnected operation? nothing. Well, I guess UIDs help, but other than that there is nothing in the protocol that is for supporting disconnected operation.

ok, so lets pretend it is UIDs that we need. Does LDAP not have UIDs? (I don't know, not really familiar with LDAP but my guess is that they must? and if not, why not a schema that had a UID field?)

also note that an IMAP server can decide to re-label all the messages with a new UID (this is why you have to keep track of the UIDVALIDITY).

ignoring that, if there is 1 vcard per email on the imap server and one client changes the contact info of a contact, they'd have to upload a new message and delete the old one. If a second client was in disconnected state and also updated the contact, when he/she goes back online... what now? OOPS. Not so grand a thing, now, is it?

IMAP4.1 is designed from the grounds up to support disconnected operation very well

> Does LDAP not have UIDs?

No, LDAP has no functionality comparable to UIDs. LDAP was originally a protocol to enable access from tcp/ip clients to the OSI X.500 directory servers. This access is meant to be executed online by nature. LDAP is definetly not designed for disconnected use in anything else than read-only configurations.

> also note that an IMAP server can decide to re-label all the messages with a new UID
> (this is why you have to keep track of the UIDVALIDITY)

The UIDVALIDITY is _only_ changed when deleting a folder and then later creating a folder with the same name again. It is only natural that in this scenario all messages have to be fetched again. From a semantic point of view this new folder has nothing in common with the original folder except that they share the same name. So why it is a problem?

> if there is 1 vcard per email on the imap server and one client changes the contact info
> of a contact, they'd have to upload a new message and delete the old one.

Yes!

> If a second client was in disconnected state and also updated the contact, when
> he/she goes back online... what now? OOPS. Not so grand a thing, now, is it?

This is a traditional conflict, which of course can always happen with disconnected mode. After all disconnected always means incoherent if more than one client is doing manipulations to messages in a single folder.

With kolab we detect this situation and then prompt the user to decide which which entry to keep or alternativly "duplicate" the very similar messages.

With the integrated KAddressbook kparts the Kolab user may then use the LDAP to look up interesting data which then gets merged into his _private_ Contacts folder. By doing so the user gets enabled to change the address entry for his personal needs (e.g. add confidential information and comments to the addressbook entry). In addition he also gains offline capablilities for free.

Later we can use ACL enabled shared imap folders to make contacts (contacts are richter than LDAP entries) accessable within workgroups.

If the community doesn't make it itself, it's likely useless. We all see how well non-funded development works with KDE. Enough companies have incentive to contribute to KDE.

Lets just point of Nautilus. Funded with 17 million USD. Useless to many.

The Kolab project is an interesting case of a successful Free Software business. Their benefit it savings in development costs, maintaince costs, where as the software is designed to be reusable in other settings.

I would like to see the state hire e.g. companies to put KDE to specified desktop usage, in line with what is needed by the state agencies and institutions. It should be cheaper than buying and applying other stuff (otherwise time is not yet ready, but will be later).

This would e.g. bring a useful clipboard. GNU/Linux as Bundestag Desktop system was canceled, because you cannot copy&paste from Browser to Office without loosing all formating and images. This is a terrible shortcoming of Linux desktop systems as of now.

Composing office documents from all kinds of other sources is the daily job of Bundestag members (and others too), but so far, no quick and dirty ways to create something of communicative exchange value.

A call for tender for Bundestag Desktop systems may one day end of with a KDE system enhancement done by a commercial company. That will be a good day.

If it must be funded explicitely, I am against it. Funding means paying more than it's worth. Believe me, a well working system is worth a lot. Certainly enough to make companies a good time improving KDE to suit Call for Tenders of institutions, companies all over the world.

> If the community doesn't make it itself, it's likely useless. We all see how well non-funded development works with KDE. Enough companies have incentive to contribute to KDE.

Actually if you look at the KDE CVS Digest, the previous article, Derek points out how many people are currently funding KDE development. Admittedly not many, but I'm one and I sponsor Andras Mantia to work on Quanta. I would say I'm in the community though so I'm not sure exactly how it all fits with your point.

> Lets just point of Nautilus. Funded with 17 million USD. Useless to many.

For whatever one's opinion was of them, and frankly their PR department annoyed me by making it sound like the second coming discovering the first Linux desktop, they basically were in the dot com bubble. VC money was flowing and they were going to make a business, although they couldn't say exactly how, but since they invented the GUI at Apple (I know you're going to say Xerox did but that doesn't read as well) they were cool to give money to. Aside from the fact that I'm scratching my head that nobody gave me a few million dollars to party with they clearly were bringing a commercial development model to Linux. I mean they had something like 17 usability people for one file manager. Nearly as many usability people as programmers and in a Linux Magazine article they could not be nailed down on exactly what their business model was. You're not going to see that repeated any time soon because millions of dollars don't usually squirt out like that for no better reason.

> The Kolab project is an interesting case of a successful Free Software business. Their benefit it savings in development costs, maintaince costs, where as the software is designed to be reusable in other settings.

This is a rational and duplicatable example. It needs to happen in Koffice.

> If it must be funded explicitely, I am against it. Funding means paying more than it's worth. Believe me, a well working system is worth a lot.

I'm not sure how to read this. I think if multiple entities fund development it's cheap, or if a large client based entity does. A lone guy like me is going to pay more than it costs to buy shrink wrap (thanks for making me feel better) but it's still worth it if you get what you want. ;-)

you and what you do with Quanta is certainly special. Special in my appreciation as well. From what I see, you make sure, your money is well directed and not wasted.

This is not how state funding works.

But Free Software is of enough benefit to society to make IBM, Oracle, HP, Sun and all big players fund what is needed as infrastructure. So why should a government step in there and order things it does not need?

Let the governments come to use Office, Project Management, CAD and other kinds of design tools, Web Design, etc. on Free Software. What do you think this will bring to enhance Free Software? If only for some strange feature gain to Apache that was not mainline before, but needed in a custom software for government...

Once we cross that line, Free Software takes off. And I am sure it will :-)

wrong ... nautilus was the client for all their services - which sucked up 1/2 or more of their burn BTW (that, plus the fancy offices). AOL's client isn't their "sole product" and Nautilus was an "mini-AOL" style play ... using massive amounts of VC money (in oversupply at that stage).

For those of us that are not (directly) involved on KDE development, but are on other free software projects, I think a really really interesting idea would be to have a (big, I guess, Sourceforge?) Kolab server for hosting free software developers vcards and calendaries. Imagine being able (using Kontact) to take a look at XYZProject maintainer calendar, invite JXCProject developer to an appoinment on IRC to discuss a patch, taking a look at QWERTYProject TODO list, or just losing some time looking at 100 random developers cards (the projects they're involved, their countries or just their photographs :) ). I think this is a really interesting idea, althought it would probably need a big big server (but, again, this could be the definitive test to see if Kolab really scales).

What kind of server machines would be suitable in your experience?
It should be possible to organize a respective donation since the Kolab/Kontact combo will surely become one of the most interesting single part of the upcoming KDE 3.2 release for the press and commercial adoption.

I am not a "KDE people", but what do you want to say to this? The article is the authors opinion, and does not contain and wrong information. What do you want to say to guys who flame because of the license? They are right, it is GPL and not LGPL. I do not really care, but if they do, I can not change it. Beat them with better software, not by wasting your time in flamewars that ain't worth it.

Im waiting for the day when I see the following on slushdot "What? you mean with OSS I'm allowd to write something better? As in do it myself? Whoah, no way I'm going back to Windows where I just use what I'm givin, its easier to complain and not do anything when I don't have a choice."

Yes virginia, you to can write Open Source Software. Personally I dont care if there are a million forks of something. The best one will rise to the top, and the crap will sit on sourceforge for the rest of eternity...

Looks like this kroupware mail client was forked off a really old version of Kmail -- i had absolutely the same problems with it, as i had before kde 3.0.
Well -- if new kdenetwork and kdepim will have all the features that kroupware has -- it will be great, but, it looks like the current version of kroupware-client was not synced with latest version of kmail. the only option for IMAP it has is so called "disconnected imap" and it has "use subscribed folders" flag always grayed -- as a result, when i tried to open my IMAP account (from server running wu-imapd) -- i got listing of my whole home directory. ;-)

this is a really good piece of software -- looks like it is going to be a really big competitor to MsOutlook/Exchange, but what if it stands for a separate industrial-use product, they should merge with latest Kmail improvements as well -- so far for everyday work have to switch to the recent kde-3.1.3