Andreas Cord-Landwehr: > On Sunday 21 August 2011 09:36:02 Dietz Pröpper wrote: > > if I got that right, current (4.7) kdepim uses akonadi as a storage > > backend for everything. > > Hi, that's the most common misunderstanding about the new KDEPIM > structure: Akonadi is not the storage backend, it is a unifying cache > for several storage backends with which applications can interact.
Thx for that clarification. Even though it confirms my fears.
> Afaik the vCalendar file storage backend and Maildir file structure
> backend are both supported by Akonadi resources as shipped with the
> current (current as in shipped with KDE SC 4.7, but not yet provided by
> Debian) KDEPIM releases. This allows easy adding of new resources for
> various backends like, e.g., a Facebook resource. [1], Yahoo calendar
> [2], Google calendar, eGroupware.
I don't need one of these. Google sync was a nice try, right now I'm
writing a Android sync that relies on something simple and not Google
based. No, will never go official, just for personal usage for the moment.
I only need a means to sync my phone to my desktop. Nothing more. And *no*
remote storage.
> Hence, this does not mean that the "old" storage resources will all
> vanish. For instance, I currently (running a self compiled KDEPIM 4.7)
> use an IMAP mail server, a vCalendar file, an addressbook as vCard
> directory, an eGroupware server for addressbook and calendar (by the
> Akonadi GroupDAV resource), and a Google calendar (by the Akonadi
> CalDAV resource).
Ack. That sounds pretty complex to me. May I send you a calendar invitation
with a funnily forged UUID and pwn u? ;-)
> The indexing and semantic desktop stuff then is a different topic: those
> things are done by the Nepomuk framework, feeding a big Virtuoso
> datasbase. For performance reasons it is possible to switch indexing of
> mails off (well, then tagging and full-text search in mails is also
> switched off).
Ack. Full text search is gone w/o akonadi integration? If I get that right,
either nepo or no indexing then that's quite a bummer for me. Sigh. And I
really loved kmail. Really. Good bye, old friend.
Even filter migration will be a nightmare. Why the fsck did I move away
from mutt 10 years ago?!
Of course I'll try on my own, wether it can still search in my 250000 msg
mail spool prior to abandoning ;-).
> Coming back to your questions: The reason why the currently with Debian
> shipped KMail application relies on Akonadi is afaik the connection to
> KAdressbook, which already switched its storage system to be cached by
> the Akonadi server with its 4.6 release. With the 4.7 release this
> switch is also done for most of the remaining PIM applications (at
> least with KMail and KOrganizer). But as with this switch all storage
> access functionality moved from the KDEPIM applications to Akonadi,
> using KDEPIM without Akonadi is not possible.
O-kay. That translates to me that I have to suffer a even worse severe
complexity explosion with future KDE. Sorry, but my head is a small one,
and I like to be able to keep understanding stuff I use there ;-).
Sigh. 3.5+x worked really nice, and now, after the worst bugs from KDE 4
went away, there is a whole lot of new hassles to expect. Time to go for
new, manageable pastures I fear.
No pun intended,
Dietz
signature.asc
Description: This is a digitally signed message part.
