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. Significant progress was made towards bringing the KDE Kolab client functionality towards a better integration with the upcoming architecture of KDE-PIM mainly associated with the Kaplan approach. All participants developed a common vision about how to proceed. No major conceptual differences remained. In addition to this some technical issues could also be resolved right away. For others basically consensus was reached on what needs to be done in the next steps.
People started to drop in on friday and left on sunday afternoon. Travel expenses and the hotel logging was payed by Erfrakon, Klarälvdalens Datakonsult and Intevation, the companies doing the Kroupware project. Bandwidth, drinks and rooms were provided by Intevation.
A kickoff meeting started the hackfest on friday afternoon. To get everyone on common ground presentations were given. After a general overview about 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 disconnected IMAP protocol. Basically this is used to save all sorts of information on the server and allowing offline changes which are later synced. This capability is not special to groupware in any way. The current KDE client implementation based on the upcoming KDE 3.1 made 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 in alternating 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 small 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 Kolab client together.
Tobias König presented the (new) resource framework to the group. He progressed 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 to have KOrganizer as a KPart and made himself familiar 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 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, who was the responsible guy from Intevation on site. He coordinated and moderated the meeting.