Participant Notes

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.