Re: Once again - akonadi google calendar sync
Vincent Frison: > On Wednesday 17 August 2011 at 15:25:59, Andreas Cord-Landwehr wrote: > > If you want to access your primary calendar/if you have only one > > calendar, you can plug in your google mail address. Also for user > > name you have to use your google mail address (with the whole address > > [username]@googlemail.com). Umm, that's another ugly hack imho. And I assumes it does not cope with the tiny differences, i.e. reminder settings. > > PS: afaik for the DAVical resource you need KDEPIM >= 4.6 > > Same problem as Dietz here ! > > Akonadi gcal ressource synchronization seems to work only the first > time, when the gcal agent is just created. > > I can see google events in korganizer but when I modify calendar (from > the google website) there's no updates in korganizer. And when I try to > sync manually with akonadiconsole and it freezes. And the only way to revive it is to delete the agent and create a new one. > About the CalDAV I'm confused : > > - DAViCal seems to be a CalDAV server, but here we need a CalDAV client > right ? > > - Altough I'm under KDE 4.6.5 I can't see any CalDAV client in the > Akonadi agents list... My kdepim is from the 4.4 clan, and it is the one from unstable. If andreas is right, that might be an explanation. > - Why a dedicated Google Calendar agent exists for Akanodi since generic > CalDAV client agent coud do the same work (but not only for Google > servers) ? Good question ;-). signature.asc Description: This is a digitally signed message part.
kdepim and akonadi
Hi, if I got that right, current (4.7) kdepim uses akonadi as a storage backend for everything. Some questions regarding that: - nowadays I have a ~/Mail with a maildirish structure. Will that cease to exist under an akonadi-based kmail? - same thing for korganizer - one vCalendar file in the fs. Will that vanish too? The background - as far as I know, akonadi uses a big, fat mysql db for it's storage. And don't ask me, how much hours I spent debugging such generic storages in the past (not especially akonadi but I have no reason to believe that it will run with less hassles). And I'm not even talking about backup and restore of parts of the data. And now the question - I don't need desktop search, I don't need fancy tagging, I need a managable, stable system (no, don't ask me, why I'm using KDE anyway). Is there a way to get completely rid of akonadi at least for mail storage, calendar storage, address storage etc? I observed that kmail from unstable blocks if akonadi is not running, complaining "weee - i need akonadi to run", and if it's true that they are so tightly coupled that would be a clear cut case for me. regards, Dietz signature.asc Description: This is a digitally signed message part.
Re: kdepim and akonadi
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. 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. 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). 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). 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. Greetings, Andreas [1] http://thomasmcguire.wordpress.com/2011/02/27/facebook-support-in-kdepim/ [2] http://cgbdx.wordpress.com/2011/04/29/show-your-yahoo-calendars-in- korganizer-so-easy/
