[Kde-pim] scripting akonadi?

[Ingo Klöcker]

On Tuesday 15 April 2008, Tobias Koenig wrote:
> On Tue, Apr 15, 2008 at 02:38:02PM +0200, M. Fioretti wrote:
> > On Mon, April 14, 2008 9:33 pm, Tobias Koenig wrote:
>
> Hej Macro,
>
> > for end users, this means that the only way for them to store email
> > into akonadi is to use mailody or kmail, until/unless somebody
> > integrates libakonadi-kde into Evolution, Thunderbird or any other
> > FOSS client,right? (this is not a critique, I just want to be sure
> > I got it right)
>
> Yes, that's correct.

Yes/no. As Tobias already tried to explain Akonadi is no storage. 
Akonadi is an interface (with a cache) between all kinds of PIM data 
storages (e.g. IMAP servers, local mbox/ical/vcard files, groupware 
servers, etc.). So the question whether one needs Mailody or KMail to 
store something in Akonadi makes no sense. You can as well use 
Thunderbird since AFAIK Thunderbird uses mbox as mail storage. So it 
would be possible to access those mbox files through Akonadi with 
Mailody/KMail.

The point is that it is irrelevant how the data gets into the storage. 
You don't need Akonadi and even less you need an Akonadi-client (like 
KMail/Mailody) for this. The question you should ask is "How do I 
access the storage via Akonadi?" And the answer to that question is: 
You must use an Akonadi-client like KMail/Mailody. But you can still 
access the stored data directly with any other client that is capable 
of accessing data stored in this particular way (mbox, IMAP, Exchange, 
groupware server).

Just as Solid provides a common and easy to use interface to your 
hardware, Akonadi provides a common and (hopefully) easy to use 
interface to your PIM data storage without you, as a developer, having 
to worry about what kind of PIM data storage you are actually talking 
to.


> But be aware that Akonadi is not a Groupware Storage, onyl a Cache...

... and, IMO even more importantly, a common interface.


> > >> If the already existing modules are not compatible at all with
> > >> Akonadi, what is the reason for this lack of backward
> > >> compatibility?
> > >
> > > We have some different concepts of handling items (mails,
> > > contacts, events etc.) which didn't fit with the standard IMAP
> > > protocol.
> >
> > OK, if you add new functionalities nobody expects them to be usable
> > by "legacy" software (ie programs not including libakonadi-kde) I
> > just expected that the basic IMAP functions would remain the same
> > as in the IMAP standard
>
> Adding legacy mode would blow up the Akonadi server unnecessary, so
> as it was not our goal to provide a real IMAP storage, but using the
> concepts of IMAP in our protocol, it doesn't make sense to be
> standard compliant.

Exactly. We chose IMAP as template for the design of the Akonadi 
protocol because IMAP is a widely used and obviously very good protocol 
and it has lots of features we also needed for the Akonadi protocol. 
But the Akonadi protocol is no variant of the IMAP protocol. It just 
happends to be a protocol that looks very similar to the IMAP protocol 
in most parts.

BTW, that's why we have decided to avoid the term "IMAP" entirely when 
talking about the Akonadi protocol. We knew that this would just cause 
confusion and obviously we were right.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20080416/7301d277/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/