KDE PIM/Meetings/Osnabrueck 3
The meeting took place from January 6th to January 9th 2005 at Osnabrück and was once again kindly hosted by Intevation. Participants included the usual bunch of KDE PIM hackers and people from the Kolab and OpenGroupware.org projects.
Lots of time was spent on discussions about the current state and the future of KDE PIM either informally or in a couple of meeting sessions. There are some more detailed reports about them at the end of this page.
In spite of distractions like the need for consumption of food we also found time for hacking, although this mainly happend during the night. As result a fair amount of bugs was fixed, some features were done like the kded module for online/offline state handling or the new recipients editor for the KMail composer and there also was time for cool stuff like the designer plugin for KParts.
As usual the meeting was not only pretty productive, but also quite some fun. We were able to complete our agenda and everyone left happy though tired. We are looking forward to the next occasion for a kdepim gathering. Numbers also speak for themselves: 133 commits were made and 40 bugs have been resolved on bugs.kde.org.
KDE 4 Roadmap
- Qt 4/KDE 4 Port
- Work on parts of kdelibs relevant for kdepim. KDE 4 will be the first opportunity to do that for quite some time due to our requirement to keep kdepim compatible to the last stable release.
- libkabc: Review fields, make some X-fields to standard fields. Cleanups
- kresources: hierarchy, priorities, profiles, app-specific activation
- KConfig XT: parametrized groups
- Convert SMTP kioslave to library
- Get rid of libical
- Move Kontact interfaces to kdlibs (?)
- Details, refactoring, cleaning up, etc.
Timescale: along with KDE 4, no special requirements
Criteria for inclusion of applications in kdepim
Status Quo, mostly rules of thumbs or common sense:
- Technical reasons (mainly dependencies)
- The people who have the work should have a strong influence
- Helps to have a reputated KDE developer as advocate
- Adhere to special kdepim rules (compatibility requirement etc.)
- General KDE criteria (license, commitment to maintain app in KDE CVS, etc.)
There was the feeling that we probably don't need a formal process (voting).
libical isn't very well maintained. There was no final stable release for years. Lutz volunteered to update our version to the last available release (0.24RC4).
kdepim data server
Tobias started the discussion by presenting his thoughts about the topic. See the [pim_daemon.pdf KDE PIM daemon slides].
- Only one copy of data in memory (provided that the apps don't duplicate the data again. That's not given)
- Only one access to the server or the data storage, even if more than one app is running (e.g. KOrganizer and the alarm daemon
- libkcal is pointer based which makes it hard to serialize the data
- No gain compared to the current library approach for locking, conflict resolution and change notification.
Idea: Different instances of a resource could share the same cache, that would avoid downloading the data multiple times.
Sindenote: It might be nice to write a resource accessing the Evolution Data Server.
- Missing conflict reslution.
- Unclear error handling
- Resource state handling (online/offline, error, initial load)
- Mixed asynchronous/synchronous loading
- Offline mode
- Persistant changes (fix for 3.4)
- kded state module (in progress)
- State handling in resources (fix for 3.4)
Make resources purely asynchronous. This makes error and state handling more straightforward. It might put an additional burden on the application developer in some cases, but normally it should be quite simple to use.
Discussion about returning results by emitting a signal instead of returning a value from a function: The requesting function can directly trigger the emit of the result signal, so that the result function is called before the requesting function returns. This has to be documented, but should be ok. It's not hard to write app code to handle this and it makes writing resources more easier. An alternative could be to guarantee that the result signal isn't emitted before the app has returned to the event loop. This would have to be enforced in the API, like it is done in the kioslave. This also requires the developer to understand the API. People seemed to tentatively prefer to allow emiting the signal in the requesting function. We will have to see in practice if this works out.
There seem to be as at least as many syncing solutions as people working on syncing code. Alone in KDE we have KPilot, KitchenSync, MultiSynk, Kandy, code in the Kolab client, KO/Pi and probably more.
libksync is a generic solution to the problem which potentially can cover all cases. Holger volunteered to better document it.
OpenSync might also be a solution. It already has some kde support. But it's in an early stage, doesn't have much documentation and is a C library.
The KitchenSync GUI is a problem because it's too hard to understand. Tobias wrote an alternative GUI (MultiSynk) which also isn't completely satisfying. Cornelius, Holger and Tobias worked on a new design for a GUI which should address the problems of the existing GUIs and is intended to replace them. Some fancy design documents were produced.
KDE PIM Osnabrueck 2005 notes compiled by Will Stephenson Present Cornelius Schumacher David Faure Lutz Rogowski Reinhold Kainhofer Marc Mutz Till Adam Ingo Klöcker Michael Brade Jakob Schroeter Tobias Koenig Will Stephenson Bernhard Reiter Mike Hauth Miriam ? Helge Hess (from Sat 8 January) Holger Freyther (from Sat 8 January) Agenda KDE PIM Roadmap Future of Syncing (Saturday, Holger) Libical replacements (Friday 1700) KDE PIM Data Server (Friday 1400) KResources (Sat 1000) Scripting Criteria for inclusion Keysigning (informal) Kolab2 + Aegypten2 demos (Sat evening) Group photo KDE PIM Roadmap -------------- CS asked "Do we need a roadmap at all?" After some discussion it was generally agreed that our roadmap can be summarised as "More of the same but better". As the public expect roadmaps to contain amazing new features ours would be seen as unexciting. Furthermore, we don't want to commit ourselves to delivering exactly the features on a roadmap, as this only sets up failure conditions. We agreed not to produce a formal roadmap. KDE PIM 4.0 issues Adapting kdelibs/kabc and kdepim to Qt4 Custom X-fields to standard vcard fields, eg IM addresses Hierarchical kresources (sub-resources) (Till) Multidialog KConfigXT Resource profiles - App specific application of these - Priorities Merging of items present in multiple resources by UID. eg where same item present in resources belonging to multiple identities - delegation case. Remove SMTP kioslave because SMTP use patterns fit poorly with ioslave semantics, and trying to implement them introduces unnecessary complexity. (Marc) Replace mimelib with kmime Replace libical - unmaintained, complex memory allocation. KPIMPart to kdelibs, or DCOP interfaces This loses us flexibility because KPIMPart would be then fixed by our kdelibs backwards compatibility rule. Moving the DCOP interfaces to kdelibs may be a good compromise. CS pointed out that kdepim can influence the KDE 4 release schedule and asked if we have any particular time requirements that should be input to KDE 4 release planning. It was felt that our plans will be doable within the expected KDE 4 time frame (1 year+). JS said that a KPart for the mail composer and view window shared between KMail and KNode would be desirable Criteria for inclusion of applications -------------------------------------- The need for a formal inclusion procedure was discussed, as Don has been pushing for this. It was suggested that a documented procedure would make inclusion easier and clearer, rather than just asking on the mailing list and never getting a definite response because noone takes responsibility for it. A voting mechanism would be one way of doing this. However, most people felt that establishing a formal voting system now would be a burden because it raises the questions of who is entitled to vote, which requires assignment of formal roles by some means, and secondly, we would be obliged to use it forever, and would be hard to change. Instead it was agreed to better document the existing informal guidelines like: - Present the application on lists - Give technical reasons why inclusion is necessary - Ask the person in the KDE PIM team who will get the most work because of the inclusion. - Find an established KDE developer to act as a sponsor. - Commit to general KDE rules (develop in CVS, commit to maintain, etc) KResources Meeting ------------------ Problems with current kresources: - Missing conflict resolution - Unclear error handling - Resource state handling - Asynchronous vs. synchronous loading Synchronous loading is simpler to implement but almost no resources give an upper limit to the loading time, blocking the UI. Async loading requires that the 'done-loading' signal is not emitted before returning to the event loop to prevent nested event loop problems. Marc pointed out that improved thread support in Qt4 will make it easier to perform async loading using worker threads. Cornelius responded that thread debugging is always a PITA. Resource offline mode We need To persist local changes when offline KDED state module State handling in resources Online/Offline mode ------------------- Resource and desktop have separate perspective on online status. A resource is simply online or offline. This affects the syncing behaviour. The desktop as a whole has 3 states Online (NL) Offline, but dial on demand (OD) Offline, permanently (OP) When going offline, the user should decide whether the transition is to OD or OP. This allows the desktop to suppress further network operations should the network environment be unreliable or completely disconnected. The preference can be recorded but the flag should be reset the next time we go online. Two stages of implementation were discussed - the first, a logical network status, whether local to the application or desktop wide. Then, a more detailed version with separate statuses for multiple networks, and a relation between resources and the networks they use. It was felt that the interaction between network status and resource state is complex and problems and other issues would turn up during implementation. Given this, we agreed to produce the first stage only for KDE 3.4 and apply our experience gained by this to the second stage for KDE 4. Will is to work on the daemon implementation. The location of the KDED module was also discussed. Kdelibs in KDE 3.4 limits its use in KDE PIM, because of the KDE 3.3 compatibility rule. Since the PIM offline state handling is more complex than eg HTTP's needs, and since DCOP allows a run time only dependency on the module, we decided it would ease development to situate the KDED module in KDE PIM for 3.4 and then move to kdelibs for 4.0. Scripting --------- There had been calls for better scripting support. The developers felt that the existing scriptability with DCOP was adequate. (Will - does this mean we need better DCOP docu or tutorials so that users are aware of the current possibilities?) KDE PIM Data Server ----------------- (Will - I didn't attend all of this meeting - can someone else complete?) Future of syncing ----------------- Kitchensync requires an API overhaul and then a completed GUI. Syncing is a general problem and we should use libksync (if only the GUI) for conflict resolution outside kitchensync, for example, when syncing local changes back when a resource goes online. Future of KPilot - at some point in the future it should be merged with kitchensync but the two architectures are very different.