about akonadi

[Kevin Krammer]

On Wednesday, 2010-03-24, Duncan wrote:

> FWIW, there's a LOT of folks who disagree with the use of akonadi and its
> database backend for something as critical as mail.  There's a huge risk
> of kde/kmail developing the reputation of eating people's mail for lunch,
> if this isn't handled well -- and arguably even if it is.  There's a
> reason kde continues to rely on text based config files, even if human-
> opaque binary formats such as the MS Windows registry are more efficient.
> 
> FWIW, that's at least one of the tasks kded is responsible for, keeping
> the text based config files in sync with the binary "ksycoca" (kde system
> config cache).  Many a sysadmin has had to become familiar with the
> kbuildsycoca/kbuildsycoca4 command to rebuild their broken kde, over the
> years, but the existence of that binary ksycoca cache does keep kde
> responsiveness up to par, while the continued existence of the text based
> config files do help to keep kde humanly configurable, should things go
> wrong.
> 
> I don't know whether kmail's going to do something similar, keep its
> maildir and mbox mail files and only use akonadi as a binary based data
> cache, or if it's killing the mbox and maildir formatted messages entirely
> for "internal" use, but I do hope it's the former, as I'm certainly not
> alone in fearing for the stability and ultimate manual editability of my
> mail store, should it be necessary, if they're switching entirely to
> binary database, not just using it as a binary data cache.

One of the common misunderstandings around Akonadi is that the relational 
database is used for storage.
Probably introduced by focusing too much on the database part than on the 
relational part.

Akonadi, or more specifically the Akonadi server, is a proxy. Interestingly 
caching proxies in other domains such as web browsing are understood in terms 
of their functionality and not their implementation details.

Maybe it is because a web proxy usually only works one-way while Akonadi works 
bidirectional or because people have difficulties understanding that mail 
servers are also "on the Internet" or because people don't care if PIM data is 
transferred repeatedly and at network speed rather than local speed.

Whatever the reason, it is still just a proxy.
One that works into both directions and can notify clients about changes 
rather than having them regularily reload the things they are interested in.

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde/attachments/20100324/0fc1ad04/attachment.sig>
-------------- next part --------------
___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.