KDE PIM
Technical Discussion
Technical Discussions
libical replacement
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 KDE PIM daemon slides.
Pros
- 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
Contras
- 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.
KResources
Current Problems:
- 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)
Possible solutions:
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.
Syncing
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.
[ Edit ]
