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.
On Saturday Helge from the OpenGroupware.org project joined us for some discussion about the GroupDAV protocol and implementation issues on the server and the client side.
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.
General Discussions
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.
- More...
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).
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
Cons
- 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.
|
|
Will's Notes
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.