[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-pim
Subject:    Re: [Kde-pim] Akonadi being a desktop-indepent standard
From:       Kevin Krammer <kevin.krammer () gmx ! at>
Date:       2008-08-18 18:58:15
Message-ID: 200808182058.29886.kevin.krammer () gmx ! at
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 18 August 2008, David Jarvie wrote:
> On Monday 18 August 2008 13:45, Kevin Krammer wrote:

> > While Akonadi server is not a storage itself as David explained, from a
> > client
> > application's point of view it acts as a storage.
> >
> > An application could still use its own storage for some data, e.g. in
> > your case email, and Akonadi for others, e.g. contacts.
>
> I find this statement a bit confusing. I presume what you mean by this is
> that you might just use whatever default storage is accessed via Akonadi
> for, in this example, contacts. But that Akonadi still doesn't actually
> have its own storage - the contacts are still likely to be stored as vcard
> data for example?

What I meant to say is that an application could still opt to access its own 
data directly, e.g. in the case of Claws directly accessing its mails however 
it stores them, but use Akonadi to access contacts, etc.

Basically a bit like KMail currently managing its mails but using KResource to 
access the addressbook.

Of course ideally all PIM data is accessed through Akonadi, so data doesn't 
have to be migrated when users switch applications, but applications are 
often very closely designed around their main data type storage method and 
might find it easier to just do other data types via Akonadi as a first step.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

["signature.asc" (application/pgp-signature)]

_______________________________________________
KDE PIM mailing list kde-pim@kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/

[prev in list] [next in list] [prev in thread] [next in thread]