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
Attachment:
signature.asc
Description: This is a digitally signed message part.