[KDE Dot News]
 faq
 flatforty
 contribute
 subscribe
 configure
 search
 rdf

 main


  Akonadi Hacking Meeting
KDE PIM Posted by Tobias König on Wednesday 25/Apr/2007, @06:01
from the hackonadi dept.
Last weekend was not only the time for the KMail Hacking Days but also for the second Akonadiˇ Hacking Meeting in Berlin, Germany. 7 KDE-PIM developers came together for 2 days at the KDAB offices in Berlin's Kreuzberg district and continued to improve Akonadi, the personal information data storage for KDE 4. Meeting the other developers in real life and discussing issues face to face always helps to find new solutions and implement crucial features in a short period of time.

The first big step was to make the setup of Akonadi as easy as possible. Now you just have to start the 'akonadi_control' application and all other components of Akonadi, including the external MySQL process, are started automatically so you can begin to read and write data from/to the storage right away.

To be able to test the functionality effectively the application 'akonadiconsole' (which is supposed to be a test application only) was extended to support displaying type specific information. Only a few lines of code later it was able to show contacts stored in Akonadi

Under the hood the code of Akonadi was cleaned up and the API of libakonadi improved for easier extension in the future.

Also the roadmap of the project was refined and the next steps to take clarified, so on the server side the API of the resources (that are plugins which communicate between the Akonadi storage and external sources e.g. groupware servers) will be simplified to allow 3rd party developers to create new resources by just reimplementing 3 virtual methods.ˇ

On the client side the next steps will include writing models for all kind of PIM data (e.g. mails, contacts, events, todos) which fetch their data from Akonadi. This task is covered by a Google Summer of Code project. Another step will be to write components like editors and viewers which work standalone with the Akonadi storage and provide features like live-update on changes and conflict resolution, new developers for these tasks are always welcome :)

In the picture below you can see the participants of this meeting:

From left to right:

  • Ingo Kloecker: KMail hacking
  • Cornelius Schumacher: KOrganizer hacking
  • Till Adam: Akonadi storage
  • Robert Zwerus: Akonadi database storage
  • Tobias Koenig: Akonadi storage and libraries
  • Frank Osterfeld: Akregator and feeds model hacking
  • Volker Krause: Akonadi poster boy :)

All in all it was a great meeting at a great location with great people.

If you are interested in helping the Akonadi team with development, documentation writing or artistic work, feel free to contacts us via mail or join the IRC channel #kontact on irc.kde.org.



<  |  >

 

  Related Links
 ·   Articles on KDE PIM
 ·   Also by Tobias König
 ·   Contact author

Thread Threshold:

The Fine Print: The following comments are owned by whomever posted them.
( Reply )

Sommer?
by zonk on Wednesday 25/Apr/2007, @17:45
"Google Sommer of Code" - those damn Germans! ;)
[ Reply To This | View ]
MySQL
by n on Thursday 26/Apr/2007, @01:41
Hi, I'm not very much at all up to date on what's going on with Akonadi, but... MySQL? Will KDE 4 require a database? (Sorry if this is a stupid question!!!)
[ Reply To This | View ]
  • Re: MySQL
    by Andre on Thursday 26/Apr/2007, @02:20
    My semi-informed reply would be: no, it will not require a database. It will just be possible to use one if you want to. I'm sure there will be support for other storage back ends as well. Still, I am not a dev in KDE-PIM, so I might be wrong.
    [ Reply To This | View ]
    • Re: MySQL
      by Till Adam on Thursday 26/Apr/2007, @03:57
      Akonadi uses the database to store metadata and usually relies on external providers/agents/ressources for the actual storage. In the mail case, for example, your mail would be in a maildir, and only a cache of things like the headers or a summary along with transient info like tags, colors, etc. would end up in the db, for easy and fast indexing, searching, etc. It can cache the payload data itself as well, though, to avoid unnessecary re-downloads, or to make offline work possible, in which case the data does end up in the database. Currently it can work with MySQL embedded and a MySQL server, so if you don't want to have a full on server running, you can simply use the single-file engine, which works much like, for example, sqlite. The database in this case is completely transparent to the user. It's merely an implementation detail, and if you happen to be running MySQL anyhow, for Amarok, KPhotoAlbum, or what have you, it can use that too. Does that clarify it a bit?
      [ Reply To This | View ]
      • Re: MySQL
        by Jakob Petsovits on Thursday 26/Apr/2007, @07:28
        > Akonadi uses the database to store metadata and usually relies
        > on external providers/agents/ressources for the actual storage.

        Hm, that sounds a lot like it could make use of Nepomuk's KMetaData.
        No idea if that satisfies Akonadi's performance criteria, though.
        [ Reply To This | View ]
        • Re: MySQL
          by Till Adam on Friday 27/Apr/2007, @02:56
          There's a demo feeder for Nepomuk, but we also store information that Nepomuk is not interested in. Sure, we'll use it.
          [ Reply To This | View ]
      • Re: MySQL
        by Ben on Thursday 26/Apr/2007, @12:58
        And out of curiosoty, why when caching the E-mail payload will the entire E-mail go into the database, instead of another maildir?
        [ Reply To This | View ]
        • Re: MySQL
          by Till Adam on Friday 27/Apr/2007, @02:53
          The idea is to keep the resources (the bits that know how to deal with a storage format, or groupware server) as simple as possible, which includes them not having to re-implement cache mechanisms over and over again, as was needed with the old kresources framework. So conceptually all caching is done inside Akonadi. We might special case well-known formats such as email to use a different on-disk store, for example maildir, for performance and robustness reasons, but in the general case the database acts as the cache. Much of the data is small (contacts, events, chat logs, etc.) and can thus be stored very efficiently in the db itself.
          [ Reply To This | View ]
    • Re: MySQL
      by superstoned on Thursday 26/Apr/2007, @04:16
      I wonder if using Strigi is an option for them? Strigi in turn supports several databases... It might make their life easier?!?
      [ Reply To This | View ]
A Wiki in Akonadi
by cmiramon on Thursday 26/Apr/2007, @06:20
Would it be possible to have a wiki in Akonadi ?

For example, my work group uses MoinMoin/dokuwiki/Mediawiki.

Akonadi on my laptop would keep a copy of this wiki. I could work on the local copy and synchronize the two versions when needed.
[ Reply To This | View ]
The Fine Print: The previous comments are owned by whomever posted them.
( Reply )

  "Feature freeze means that everyone has a bad feeling when they change something, almost nothing more." -- Stephan Kulow
KDE®, "K Desktop Environment", "KDE Dot News", "got the dot?" and the KDE Logo® are trademarks or registered trademarks of KDE e.V. in the European Union, the United States and other countries. All other trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the poster. The rest: Copyright © 2000-2008 KDE e.V. for The KDE Project. For further information or comments on this site, please contact the Webmaster.
[ home | post article | flat forty | subscribe | search | rdf ]