More on KDE Groupware

e8johan writes "The KDE PIM Team will integrate all their applications into one common interface and create an Outlook-like application.This is being done in the Kroupware project commissioned by the German government. There is a prototype of KOrganizer with KMain embedded into it (shots 1, 2), and another prototype with KMain running as a KPart in Kaplan (shot 1, 2, 3). This looks hopeful and if they manage to build the application as flexible and modular as other KDE projects this will hopefully mature into something great." Kroupware is a catchy name, but I wonder if the KDE team is aware of the English word croup.

Re:evolution

[cxreg]

A large part of this project is the server-side, grouping together existing applications (cyrus IMAP, OpenLDAP, etc) to provide a "Groupware server".

You should be able to use Evolution with all of those parts anyway (and actually, currently I don't think Evo supports stuff like LDAP and shared calendering, a project like this might influence support for such things).

Temporary name

[Otter]

Kroupware is a catchy name, but I wonder if the KDE team is aware of the English word croup.

It's been pointed out to them and they've explained [kde.org] that it's a working name, not a final decision.

Meanwhile, I've tried to suggest that the developers of the Perl/QT [kde.org] user interface compiler choose a less disgusting name than "puic" ...

Re:evolution

[Anonymous Coward]

So what? It's a matter of choice. Besides, while evolution runs fine, it renders terribly with too many 'assumed' window/font sizes, i.e., does not scale well to power users with 1280x1024 and 1600x1200 screen sizes. In contrast, Outlook rendering scales well. KMail adherence to KDE style/theme scales well, and it is replete with expected mail client features.

It would benefit all to see it all bundled into one, integrated package and UI.

Re:evolution

[KeyserDK]

i know evolution does support LDAP.

dunno about the shared calender stuff =)

WAKE UP!

[brunes69]

You said to wake you up...

From the link in the article...Kolab is the name of the server component.

Archetecture Paper [kroupware.org]

Once again a /. comment that goes off ranting without folowing any of the links in the story...

Re:WAKE UP!

[fusiongyro]

How do you take a screenshot of a server?

BTW: if you read about the server components [kroupware.org], you should have noticed that most of these things exist already (postfix, cyrus, apache, inetd, proftpd, openldap2). Kolab is just going to tie them together and slap a pretty administative UI on top.

--
Daniel

Re:Ugh...

[rseuhs]

Kaplan is merely a container of those programs.

The components (KMail, KOrganizer, KNode and knotes) will continue to be available seperately

So everybody should be happy, right? - Wrong, some people will always whine, no matter what.

Once you have used Exchange, you'll understand.

[FreeLinux]

Exchange goes far beyond what you describe. First by centralizing these functions it makes it easier to manage the single application, rather than several different ones. Backups are a breeze.

The calendaring goes beyond what you describe. Not only can you receive a meeting invitation, you can also share calendars or entire mail boxes. This is a common practice, where managers will share their calendar or mailbox with a secretary so that the secretary can perform various functions, like setting appointments, for the manager while they are out of the office. If you call and would like an appointment with the manager, you will more likely get his secretary who, if they are using Exchange, can look at his calendar and tell you when he would be available for such an appointment. Then the secretary can register the appointment in the manager's Outlook calendar. Beyond that still, even if you do not care to share a calendar with anyone, people who wish to schedule meetings with you can immediately see if any and all of the meeting participants are available at that particular time. They cannot see what is on the calendar but, they can see that you have something scheduled and are unavailable at the time they are trying to schedule the meeting for. This makes meeting scheduling much faster than the older method of offering several different times to various participants and hoping that they will respond and that their responses do not conflict with other meeting participants.

Then there is the additional feature of Exchange called public folders. Here you can store publicly available discussion forums, rather like USENET. Also, you can store forms, bulletin boards and any other public information that you like. You can also restrict access to these "public" areas to certain people.

Exchange 2000 also has a NNTP server built in so you can host USENET news or your own NNTP news groups.

Then there is the BIG difference. Exchange is extensible meaning that other applications can be layered on top of or integrated into Exchange. These third party applications include things like document management, voice mail, Faxing and much much more.

Don't forget, Outlook is not the same as Outlook Express and that Outlook is simply a client application. It is the Exchange server at the back end that really provides the great services that people want. Many of these service are mission critical to a LOT of businesses. Also, don't forget that although you claim not to like Outlook, the VAST majority of users like it very much. They like having everything right there in a single convenient location and for them, it just works!

Re:evolution

[GOD_ALMIGHTY]

From the design documents listed on their site, this doesn't look like much on the server side. They're going to 'jerry-rig' the asynchronous shared calendaring hack that Bynari uses. This is still not the shared calendaring that exchange provides.

These guys should be supporting and helping http://www.opencap.org, which is implementing the IETF draft for real-time shared calendaring. What they are doing is pushing static free-busy files to an FTP server then using a Calendar folder in the IMAP server for storage.

This does not enable real-time calendaring. From what I can tell, they aren't writing anything for the server-side, just configuring known packages. I can understand that their goals and time restrictions may mean that the methodology they are using for calendaring is the best they can do right now. In fact I believe this is the case, since you would pretty much have had to come across the CAP protocols doing the research that would lead you to the solution they've chosen.

I think this is a great project, and I hope they write some nice server admin tools, but this is not the 'Exchange Killer' that everyone seems to be touting it as. It is a nice start.

If you want an 'Exchange Killer', help out http://www.opencap.org. This guy has the right design (LDAP and SASL support) that will allow it to integrate with Cyrus IMAP and OpenLDAP. Since most of the OpenSource calendaring client projects (Evolution, Mozilla, etc) use libical, it should be relatively small amounts of work to make sure they work with OpenCAP, once it's ready.

BTW, Evolutions history with LDAP support has completely sucked. I noticed the last release had some work done on LDAP, but it had a ways to go last time I tried it. I want the ability to add addresses to the LDAP address book from Evolution (assuming the LDAP server has the correct ACL's).