Tobias started the discussion by presenting his thoughts about the topic. See the KDE PIM daemon slides.
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.
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.