On the first weekend of 2003, Intevation, along with the other companies participating in the Kroupware project, Klarälvdalens Datakonsult and Erfrakon organized and sponsored a KDE PIMHackfest in Osnabrück, Germany. The main purpose was to define a roadmap on the future of personal information management in KDE. Berndhard Reiter from Intevation wrote down a nice summary (included below) for your convenience. Thanks goes to the companies involved for making this meeting possible, and the developers involved for their participation.

This is a short summary report about the
Kroupware/Kaplan Hackfest that took place
on the first weekend in 2003 in Osnabrück, Germany.

The overall goal of the meeting was reached with
significant progress being made towards bringing better integration between the KDE Kolab client
functionality and the upcoming
architecture of KDE-PIM (mainly associated with the Kaplan approach).
All participants developed a common vision about how to proceed and no major conceptual differences remained. Some technical issues were resolved right away and consensus was also reached on what needs to be done
in the next steps.

People started to drop in on Friday and left on Sunday afternoon. A kickoff meeting started the hackfest on Friday afternoon.
To get everyone on common ground, presentations were given.
After a general overview of the Kroupware project,
more technical introductions to the currently implemented KDE Kolab client
and the Kaplan approach followed:

At the core of the Kolab architecture stands the standards-based IMAP protocol.
Basically, this protocol is used to save all sorts of information on the server
and allowing offline changes which are later synced.
This capability is not specific or restricted to any particular groupware.
The current KDE client implementation based on the upcoming KDE 3.1
makes KMail, KOrganizer and KAddressbook save their information
using disconnected IMAP controlled by KMail.

Kaplan basically tries to provide access to the capability
of the KDE components relating to personal information management.
In this sense, it needs all KParts done cleanly in a way that the
single applications can still work standalone
without being embedded in Kaplan.
Kaplan therefore does not add much logic itself or solve
the problem of interaction. It only forces a clean design and
usage of common configuration and interaction methods.

After the problem space was explored,
work was done alternately between
working groups and meetings for coordination and discussions of new findings.
As natural for an event like this,
many successful informal conversations also took place.
In the following you can read a few lines on
what was archived by the different people on this first January weekend.

David Faure and Daniel Molkentin analysed DCOP and found
that a better general DCOP service starter is needed
which was subsequently implemented.
DCOP error handling got examined and a some documentation
on how to properly write clean DCOP functions was produced.
KAddressbook was ported as an example.
It is clear that more general DCOP interfaces need to be defined
so that KMail and KOrganizer can act as a Kolab client together.

Tobias Koenig presented the new resource framework to the group.
He made more progress on its implementation and started porting libkabc
to the new framework.

Bo Thorsen and Steffen Hansen worked on various bugfixes
of KMail and KOrganiser code and ported most of KMail/Kroupware to HEAD.
They, together with Karl-Heinz Zimmer, answered many
questions about the code they contributed for the Kroupware project.

Lutz Rogowski made some progress towards using KOrganizer as a KPart
and familiarised himself with Kitchensync.

Cornelius Schumacher developed a concept for the iCalender parsing
and worked on porting KOrganizer to the new resource framework.

Günter Schwann fixed a KParts bug and started on the "imap"-resource
for KOrganizer.

Ingo Klöcker helped porting KMail/Kroupware to HEAD
and did miscellaneous KMail cleanups.
Marc Mutz worked on KMail, especially the IMAP account code
and prepared and conducted several code merges to HEAD.
Marc also helped to prepare the meeting.

Having many developers on site gave us the good opportunity
to discuss the long standing questions whether to move KMail, KNode, Korn and related libraries to
the kdepim module. The question was approached with structured discussion.
In a first step, pro and con arguments were collected.
Everybody had to wait for the second step to give
their opinion on how to weight the arguments.
In the end, consensus was reached and the move was favoured. More details on the results will be reported by
the respective developers on the appropriate mailinglists.

This report is brought to you by Bernhard Reiter (of Intevation), who coordinated and moderated the meeting. Travel expenses and the hotel accommodations were paid for by Erfrakon,
Klarälvdalens Datakonsult and Intevation,
the companies behind the Kroupware project.
Bandwidth, drinks and rooms were provided by Intevation.

A lot has happened since then:

KMail, KNode, Korn and related libraries have been moved to the KDE PIM CVS module as planned

That sounds a little painfull to have to wait for 3.2 - 3.1 will be final in a few days and knowing the KDE team faithfull bug hunting exercise theres sure to ber 3.1.1-3.1.3 or higher! that gonna be b4 we see 3.2 - Now to tell the the truth I don't think i can wait that long!!!

Since you say there been CVS commits of the code, i'm going ahead and compiling the CVS version, with these new tools i believe KDE is truely ready for the enterprise!

Maybe this is the wrong place to mention this! I say an excellent app written by Tomás Espeleta on http://hotwayd.sf.net This would be excellent to support in KMail client for Home users who might not have a Kolab Server.

kmail will not move over the top until it can ingest PKCS12..etc files to perform signing/encryption/verification of email. The only program that can do this is netscape, and it does not have PDA support. So I am stuck using 2 apps. I am not sure why all linux email apps can use PGP, but none of them use certificates from verisign or any other certificate authority.

That depends on the distributors. There are already Debian packages for all necessary libraries. Whether there will also be RPMs from SuSE, Rethat, Mandrake, ... can only be answered by those companies.

But there is a lot of motivations for the future: an integrated multimedia framework with video (arts allowing things like non-linear video editing, ...), avanced framework for image-composing like Quarkz(maybe XRENDER + Kpainter), avanced programming envirotment (multilanguage develop with Kdevelop + UML editing with Umbrello, ...), fully integration with new internet tecnologies and distributed programming (dotGNU -with Qt# and Kde#- or, why not, konqueror XUL support to get rapid remote-applications within KDE)... A lot of dreams for the future...

Neat idea ... all you need for XUL is something that will render it ...

The neatest thing about mozilla is not that it renders webpages ... it's that mozilla *IS* a webpage. The whole application is XML/RDF rendered by xpcom .... I wonder if hacking an xpcom kioslave would let KDE render mozilla/XUL applications?!!!

Maybe that's what Trolltech wants to do in a future:
- They have a XML format to represent interfaces (*.ui)
- They have support for a ECMA like scripting language: QTScript
- You can render ui files dynamically with an library (libqtui ?)
- They even have support for a component model like COM

So, the only remaining thing is to distribute the aplications over HTTP and maybe, fill some small holes.
What I wouldn't like from this model:
- I think .ui is not as clean as XUL. The box-oriented layout is very useful
- Styles: skins in XUL are described using CSS, another web related technology. I haven' studied this for Qt, but maybe it's not generic enought
- What happens with other technologies: XBL, ...

In the other hand, Qt is a wide used library with interesting features; you could compile your interfaces when speed get critical.

I've actually written some code for this sort of thing - eg. it lets you export QListView's as HTML. I remeber talking to Harvord from Troll Tech about it the linux expo in San Francisco a few years ago. The main difficulty in using this to make apps usable over HTTP is latency. The approach I think most successful is to make a headless port of Qt which can do this stuff natively, and make the rendering code generate HTML with JavaScript in it. The script would handle all the stuff that needs to operate with low latency, then things like pressing an Ok button would connect back to the server.