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 PIM Hackfest 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
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:
Have a look at the KDE PIM homepage for further status reports.
Hold your breath for KDE 3.2!