[Kde-pim] Osnabrueck Meeting Notes: Akonadi

Tue Feb 5 07:46:19 GMT 2008

On Tue, Feb 05, 2008 at 12:12:40AM +0100, Volker Krause wrote:
> Hi,
Hej Volker,

thanks for the detailed TODO. Shall we put it into SVN later?

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 Plans for 4.1
 -------------

 Move libakonadi and at least libakonadi_kmime to kdepimlibs.
 We'll probably have a meeting in March to do API reviewing/fixing for that.
 See also Cornelius' mail.

 Feedback by current users
 -------------------------

 - Cache policies are missing, only a complete fetch of all folders is
   currently possible, see below.

 - There is no way to set and retrieve the size of an item, neither for
   the current item size nor for the full item size reported from the
   backend (supported eg. by IMAP, POP3).
   Proposed solution: Add generic item property to set/get the size,
   unless an extra item part this allows server side support for eg.
   determining the folder size.

 - Item internal add date: Hm, I don't remember why this was needed,
   but it's basically there already in the server and just needs
   to be exported in the client API.

 - Support item streaming in itemsync.cpp to avoid keeping all
   items in memory, which is especially a problem for non-incremental
   snycing.

 - Add API for type-safe access to additional item parts (those not
   covered by the payload), similar to what we have for collection
   attributes.

 - Configuration handling. Currently resource agents show their own
   config dialog on request, there is no way of integrating this into
   an application dialog or eg. implement a wizard.
   Proposed solution: Embedding of resrouce/account configuration is
   not used by any current application, all use separate dialogs.
   So, we don't need to change that part, except for adding a parameter
   for the parent window id to the method to fix the usual window
   management problems with out of process dialogs.
   Additionally we'll add an interface to set and retrieve single config
   settings from the resource, using a string key and a variant value.
   ResourceBase will implement those methods and map them to a
   KConfigSkeleton (KConfigXT generated code) for convenience. This
   will allow configuring resources from external applications such
   as wizards or migration tools.

 - Showing additional dialogs (eg. password request) from resources:
   Add a method to ResourceBase to request a parent window id for them.
   Additionally add a systray icon (eg. to akonadi_control) to have a
   hook into the GUI for the background processes to show status, progress
   or error messages etc.

 - Limiting ItemFetchJob to data in the local cache is still not possible,
   causing a full download of everything if any search index feeder is
   running.

 - Conflict detection: We might need a convenience API for resources to
   remember the last seen revision to be able to detect conflicts when
   writing changes from the backend to Akonadi.

 - The API for collection and item modification jobs is really broken,
   telling the job again is way to cumbersome.

 Cache policy requirements
 -------------------------

 Cache policies are supposed to specify which data is kept locally, for
 how long and how/when it is downloaded. We came up with the following
 requirements which should cover everything we have up to now:

 There is one cache policy per collection, it can either define to
 inherit all properties of the policy of the parent collection (the default)
 or specify the following values:

 - The item parts that should be permanently kept locally and are downloaded
   during a collection sync (eg. full mail vs. just the headers).
 - A time up to which non-permantly cached item parts have to be kept at
   least (0 - infinity).
   [Do we also need a size limit for the cache as well?]
 - Wether or not a collection sync is triggered on demand, ie. as soon
   as it is accessed by a client.
 - An optional time interval for regular collection sync (aka interval
   mail check).

 This has been mostly implemented during the meeting, together with the
 necessary interface to only sync a single collection.

 Nepomuk integration
 -------------------

 The new idea for implementing searching is the following:

   For every mimetype there will be a nepomuk feeder agent, which
   listen to all available collections and as soon as an item of the
   monitored mimetype is added or removed, it will extract all meta data
   and push them into nepomuk storage via Soprano (Qt-only DBus
   interface).

   For searching the data we'll introduce a new daemon (queryserver)
   which provides a DBus API to Akonadi and uses the Soprano API to
   access Nepomuk.
   That daemon emulates a XESAM-like service (e.g. persistent searches),
   however its query language is SparQL instead of XML and the API is
   object oriented.

   The XesamManager in Akonadi will be renamed to SearchManager and
   adapted to make use of the queryserver.

   The functionality of queryserver might be integrated into Nepomuk
   later, so see it as a rocking temporary solution ;)

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Ciao,
Tobias
-- 
Separate politics from religion and economy!
The Council of the European Union is an undemocratic and illegal institution!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080205/c4605632/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/