Promo/Guidance/Specific KDE Technology/Akonadi: Difference between revisions

From KDE Community Wiki
(first version, mostly adopted from Nepomuk)
 
 
(10 intermediate revisions by 5 users not shown)
Line 1: Line 1:
=Akonadi communication strategy=
=Akonadi=
Akonadi is complex, under-the-hood, and does not seem to have immediate benefits - this page can help communicate to end-users what Akonadi is good for. We recommend reading through the entire page.


Communicating to users what Akonadi is and is supposed to do is rather dificult. Akonadi is fairly low-level, and does not bring immediate benefits or features not available before like Nepomuk - at first. As with Nepomuk, we don't know what the future benefits will turn out to be.
==What is Akonadi?==
Akonadi is a framework that can understand and manipulate email, calendaring and contact information, or PIM (Personal Information Management) data, from different sources.


However, we need to communicate better about Akonadi as it can lead to issues, is seen as another 'piece of bloath' and another big promise with little result. By providing clear information and good examples of what Akonadi will do for the user, we can counter these issues.
===What can Akonadi do right now?===
In short, not much. KDE PIM 4.4 is still in its infancy stage as far as harnessing Akonadi's power is concerned. Unfortunately the benefits of Akonadi will only be seen when more applications start using it. Luckily developers are well aware of this and applications, such as KDE PIM 4.5, are in due course to providing these benefits.


However at this point in time, Akonadi can:


==Poster Boy Features==
* Connect KDE Groupware apps with GMail and have your contacts imported.
* Synchronise with Google Calendar.
* Synchronise with Nokia's phone calendar.


===Meme===
===Advantages Akonadi will provide in the future===
There are fun and useful things you can do with Akonadi today.
* KDE PIM 4.5 will be able to connect to most calendar servers out on the web, out of the box.
* Seamless access to PIM data from any single application (email, calendar, todo, contacts, etc) from any source, including:
** Local file
** IMAP server (with support for push-IMAP)
** GMail/GCal
** Phone, mobile device or palm pilot
** Network file shares
** ... and really everything: Akonadi's modular structure make it easy for developers to write "connectors" to allow Akonadi to access data from any service.
* Synchronize with other PIM applications and services easily.
* Merge data into single "stream", such as data from Facebook, GMail, Hotmail, LinkedIn, and other social/PIM services to allow new innovative ways to interact with our data.
* More flexibility to interact with PIM data, such as virtual folders based on SPARQL queries.
* Perform all these functions continuously in the background instead of having to run multiple groupware applications. This increases the performance of applications as it removes the need for each individual application to load PIM data repeatedly.
* Akonadi scales to your data as it supports pluggable backends (currently MySQL is implemented). For example, having a large amount of mail is no problem for Akonadi while other solutions will struggle with >50,000 messages. With modern storage you won't have to delete email anymore.
* Performance improvements within applications, such as faster IMAP access, searching and tagging.
* For developers, Akonadi is far easier to work with. While it might take some time to get it implemented in applications, it will make it easier to maintain, improve, and even fix bugs.


===Purpose===
===Possible problems faced by users===
Spread awareness of how Akonadi is actually useful to people in their day-to-day lives, justifying it's existence on their computers.
* Packaging issues: packagers are not yet familiar and dependencies are new and sometimes still immature. In time, the out-of-the-box experience will get better.
* Akonadi sometimes complains a bit too much, this is being worked on.
* During migration it is possible some account settings are lost.
* Memory: Virtuoso + MySQL costs more memory and more disk space.
* KMail starts faster, but slower if Akonadi is not yet running.
* On-server filtering for POP3 not yet implemented
* Attachment loading on-demand not yet implemented
* Server-side IMAP searching doesn't work, searching goes through Nepomuk
* UID+ is required by the server, otherwise IMAP won't work (many servers support it, but don't report it working). Workarounds for GMX, GMail are already in.
* We're not quite sure if Google IMAP works yet. (please test, Sebas)


===Implementation Strategy===
=== Possible innovations brought by Akonadi ===
Use a set of "poster boy" features for the semantic desktop as examples whenever discussing Akonadi and repeat them in every interview / article we do where PIM comes up. We should have three good examples of new such features for each major KDE release.


===Talking Points===
For example, applications like KOffice can’t access data from KDE PIM apps right now unless they are running. Akonadi runs as a background service so it’s data is always available. For example, you can have a docker in KOffice which attaches the current document to a new calendar event (currently in development). You can invoice app sending mails by itself instead of having to even start KMail. We could drag and drop groupware data streams to your Plasma Desktop and have them easily accessible there, live updating once something happens. Think email threads, chat logs, shared notes etc. The possibilities are endless.
* If you tag an image in your image viewer, the tag becomes visible in your desktop search. That's how it should be, right?


We want these innovations to occur, and we'd appreciate ideas from the community on what to create. Add your own in the [http://forum.kde.org/viewforum.php?f=83 KDE Brainstorm]. Here is [http://forum.kde.org/brainstorm.php#idea83326 one of the top-voted ideas] in the KDE Brainstorm that has been brought to a reality via Akonadi:


==You Won't Even Know Your Using It==
[[Image:Plasma calendar.jpg|thumb|center|200px|Plasma Calendar]]


===Meme===
==The Migration towards an Akonadi based PIM Suite==
Akonadi bring not only new features, it is also helping improve things we already use and rely on all the time as a "behind the scenes" technology. Often you won't even know you're using it, other than it making the software experience better.


===Purpose===
The next big thing in terms of showcasing the benefits of Akonadi lies in the upcoming KDE PIM 4.5. This new version of Kontact is undergoing massive infrastructural changes. It is currently largely stable and feature-complete, and is assumed to be safe for standard usage. Even though data loss is highly unlikely and the remaining problems should only lie with weird and legacy setups, the KDE PIM team realises the risk of compatibility issues and is placing a large focus on the stability of the upcoming release. This will be done by releasing monthly betas - discouraged for the general public with vital data but necessary to ensure a stable final release.
The goal is to provide counterpoints to "I don't want to tag all my stuff
manually" and "I don't care for this new fancy stuff, I am happy with
the current functionality I have as it is".


===Talking Points===
During this migration period, the KDE PIM team would ensure that all possible migration scenarios are covered, as well as ensuring that rolling back to a traditional non-Akonadi Kontact (ie, PIM 4.4) is possible. Migration to and from Akonadi and non-Akonadi based PIM suites will be automated and with minimal data loss (at most, meta data such as flags will be lost). For extra security, it is recommended for testers to backup the $KDEHOME directory (usually ~/.kde). Obviously any and all bug reports should be reported.
* Akonadi is using Nepomuk to power search and information retrieval features we take for granted such as contact lists. When Kontact is fully Akonadi powered,, you'll end up using the semantic desktop tools without even knowing it whenever you use Kontact. The result is your email/contacts/calendaring system will work better, thanks in part to the semantic desktop framework.


===Upcoming Features and Improvements===
* UI does not block anymore while filtering emails locally. This is the most hated KDE bug, and could previously not be fixed in a satisfying way. Akonadi's process separation makes it possible to fix this now.
* Exchange support is within reach now (legwork done by the Samba team)
* Fast virtual folders will come to full potential
* Nepomuk features to link emails and contacts (and other semantic resources)
* Clients for other platforms: KMail mobile, KMail on Windows
* Fancy Plasma stuff (e.g. Lion Mail, Calendar integration is even already there)
* Finer-grained native control over caching, e.g. attachments using Disconnected IMAP or per folder policies.


==Functionality Challenges Are Being Addressed==
===Information for Distro Packagers===
* Distros not willing to test the setup / packages should NOT ship
** mysql setup / apparmor
** prevent addressbook screwups
* Nepomuk has to be on (no indexing needed), otherwise Kontact completion, groups won't work (this includes SC 4.4 as well).


===Meme===
===Groupware Support===
The foundations of Akonadi are maturing.
The following groupware servers can be expected to work with Akonadi-based Kontact components:
* Kolab,
* OpenXchange (not Exchange),
* Scalix,
* OpenGroupWare,
* EGroupware,
* TINE,
* Google,
* Zimbra
* other GroupDav-based servers
* Groupwise: use compatibility bridge
* Any Kontact KResource plugin: the compatibility bridge can be used for everything that doesn't have an akonadi resource. This needs some configuration by user, though automatic migration should work, please report bugs if you encounter problems here.


===Purpose===
==FAQ==
As a new technology, Akonadi has been shipped in various broken states by some of our downstreams and has historically used technologies that are new and even immature. This is improving, and we need to spread the word so that Akonadi's reputation can be rid of these "early days" hiccups.
* I don't like Akonadi. Can I not use Akonadi?
 
** In short, no. Akonadi is expected to become an integral part of KDE SC. Any problems you are facing now regarding Akonadi are a regretted and unfortunate stage in the introduction of any new technology. A better course of action would be to actively provide constructive debugging information to make a better KDE SC for everybody.
===Talking Points===
* How/where does Akonadi store my data?
* Due to being a new kind of technology being brought into mainstream use for the first time, tools for the technologies that underpin Akonadi were few and mostly academic in nature: they worked, but performance was not a goal. Akonadi is using more and more infrastructure that has been written with production use and performance in mind.  
** Akonadi does NOT store user data. It caches it. The basic storage is still the traditional format, be it an online server (imap) or local files (ical calendar files). As for managing this, the "akonaditray" utility's configuration window can be used to manage resources, but this is not yet recommended for use by the uninformed.
 
* Is Akonadi part of this whole semantic desktop thing?
* As a new kind of technology, KDE packagers were not familiar with it or all the techniques to deliver it in a well functioning manner to their (and our) users. As packagers are gaining experience with Akonadi, the quality of system integration is improving and a higher quality user experience is resulting due to improved packaging and out-of-the-box configuration.
** Akonadi works with Nepomuk, in that it feeds Nepomuk with certain information about it's data which will then be used to provide a semantic desktop.
* Why not delay Akonadi integration?
** Delaying would mean maintaining several versions of the KDE PIM apps, thus wasting resources. Also, developers won't get to see Akonadi in action and have less incentive to start writing cool connectors, delaying the arrival of real benefits for the users even more. Finally, delaying would mean less testing, leading to more bugs and more delays.

Latest revision as of 23:31, 5 March 2012

Akonadi

Akonadi is complex, under-the-hood, and does not seem to have immediate benefits - this page can help communicate to end-users what Akonadi is good for. We recommend reading through the entire page.

What is Akonadi?

Akonadi is a framework that can understand and manipulate email, calendaring and contact information, or PIM (Personal Information Management) data, from different sources.

What can Akonadi do right now?

In short, not much. KDE PIM 4.4 is still in its infancy stage as far as harnessing Akonadi's power is concerned. Unfortunately the benefits of Akonadi will only be seen when more applications start using it. Luckily developers are well aware of this and applications, such as KDE PIM 4.5, are in due course to providing these benefits.

However at this point in time, Akonadi can:

  • Connect KDE Groupware apps with GMail and have your contacts imported.
  • Synchronise with Google Calendar.
  • Synchronise with Nokia's phone calendar.

Advantages Akonadi will provide in the future

  • KDE PIM 4.5 will be able to connect to most calendar servers out on the web, out of the box.
  • Seamless access to PIM data from any single application (email, calendar, todo, contacts, etc) from any source, including:
    • Local file
    • IMAP server (with support for push-IMAP)
    • GMail/GCal
    • Phone, mobile device or palm pilot
    • Network file shares
    • ... and really everything: Akonadi's modular structure make it easy for developers to write "connectors" to allow Akonadi to access data from any service.
  • Synchronize with other PIM applications and services easily.
  • Merge data into single "stream", such as data from Facebook, GMail, Hotmail, LinkedIn, and other social/PIM services to allow new innovative ways to interact with our data.
  • More flexibility to interact with PIM data, such as virtual folders based on SPARQL queries.
  • Perform all these functions continuously in the background instead of having to run multiple groupware applications. This increases the performance of applications as it removes the need for each individual application to load PIM data repeatedly.
  • Akonadi scales to your data as it supports pluggable backends (currently MySQL is implemented). For example, having a large amount of mail is no problem for Akonadi while other solutions will struggle with >50,000 messages. With modern storage you won't have to delete email anymore.
  • Performance improvements within applications, such as faster IMAP access, searching and tagging.
  • For developers, Akonadi is far easier to work with. While it might take some time to get it implemented in applications, it will make it easier to maintain, improve, and even fix bugs.

Possible problems faced by users

  • Packaging issues: packagers are not yet familiar and dependencies are new and sometimes still immature. In time, the out-of-the-box experience will get better.
  • Akonadi sometimes complains a bit too much, this is being worked on.
  • During migration it is possible some account settings are lost.
  • Memory: Virtuoso + MySQL costs more memory and more disk space.
  • KMail starts faster, but slower if Akonadi is not yet running.
  • On-server filtering for POP3 not yet implemented
  • Attachment loading on-demand not yet implemented
  • Server-side IMAP searching doesn't work, searching goes through Nepomuk
  • UID+ is required by the server, otherwise IMAP won't work (many servers support it, but don't report it working). Workarounds for GMX, GMail are already in.
  • We're not quite sure if Google IMAP works yet. (please test, Sebas)

Possible innovations brought by Akonadi

For example, applications like KOffice can’t access data from KDE PIM apps right now unless they are running. Akonadi runs as a background service so it’s data is always available. For example, you can have a docker in KOffice which attaches the current document to a new calendar event (currently in development). You can invoice app sending mails by itself instead of having to even start KMail. We could drag and drop groupware data streams to your Plasma Desktop and have them easily accessible there, live updating once something happens. Think email threads, chat logs, shared notes etc. The possibilities are endless.

We want these innovations to occur, and we'd appreciate ideas from the community on what to create. Add your own in the KDE Brainstorm. Here is one of the top-voted ideas in the KDE Brainstorm that has been brought to a reality via Akonadi:

Plasma Calendar

The Migration towards an Akonadi based PIM Suite

The next big thing in terms of showcasing the benefits of Akonadi lies in the upcoming KDE PIM 4.5. This new version of Kontact is undergoing massive infrastructural changes. It is currently largely stable and feature-complete, and is assumed to be safe for standard usage. Even though data loss is highly unlikely and the remaining problems should only lie with weird and legacy setups, the KDE PIM team realises the risk of compatibility issues and is placing a large focus on the stability of the upcoming release. This will be done by releasing monthly betas - discouraged for the general public with vital data but necessary to ensure a stable final release.

During this migration period, the KDE PIM team would ensure that all possible migration scenarios are covered, as well as ensuring that rolling back to a traditional non-Akonadi Kontact (ie, PIM 4.4) is possible. Migration to and from Akonadi and non-Akonadi based PIM suites will be automated and with minimal data loss (at most, meta data such as flags will be lost). For extra security, it is recommended for testers to backup the $KDEHOME directory (usually ~/.kde). Obviously any and all bug reports should be reported.

Upcoming Features and Improvements

  • UI does not block anymore while filtering emails locally. This is the most hated KDE bug, and could previously not be fixed in a satisfying way. Akonadi's process separation makes it possible to fix this now.
  • Exchange support is within reach now (legwork done by the Samba team)
  • Fast virtual folders will come to full potential
  • Nepomuk features to link emails and contacts (and other semantic resources)
  • Clients for other platforms: KMail mobile, KMail on Windows
  • Fancy Plasma stuff (e.g. Lion Mail, Calendar integration is even already there)
  • Finer-grained native control over caching, e.g. attachments using Disconnected IMAP or per folder policies.

Information for Distro Packagers

  • Distros not willing to test the setup / packages should NOT ship
    • mysql setup / apparmor
    • prevent addressbook screwups
  • Nepomuk has to be on (no indexing needed), otherwise Kontact completion, groups won't work (this includes SC 4.4 as well).

Groupware Support

The following groupware servers can be expected to work with Akonadi-based Kontact components:

  • Kolab,
  • OpenXchange (not Exchange),
  • Scalix,
  • OpenGroupWare,
  • EGroupware,
  • TINE,
  • Google,
  • Zimbra
  • other GroupDav-based servers
  • Groupwise: use compatibility bridge
  • Any Kontact KResource plugin: the compatibility bridge can be used for everything that doesn't have an akonadi resource. This needs some configuration by user, though automatic migration should work, please report bugs if you encounter problems here.

FAQ

  • I don't like Akonadi. Can I not use Akonadi?
    • In short, no. Akonadi is expected to become an integral part of KDE SC. Any problems you are facing now regarding Akonadi are a regretted and unfortunate stage in the introduction of any new technology. A better course of action would be to actively provide constructive debugging information to make a better KDE SC for everybody.
  • How/where does Akonadi store my data?
    • Akonadi does NOT store user data. It caches it. The basic storage is still the traditional format, be it an online server (imap) or local files (ical calendar files). As for managing this, the "akonaditray" utility's configuration window can be used to manage resources, but this is not yet recommended for use by the uninformed.
  • Is Akonadi part of this whole semantic desktop thing?
    • Akonadi works with Nepomuk, in that it feeds Nepomuk with certain information about it's data which will then be used to provide a semantic desktop.
  • Why not delay Akonadi integration?
    • Delaying would mean maintaining several versions of the KDE PIM apps, thus wasting resources. Also, developers won't get to see Akonadi in action and have less incentive to start writing cool connectors, delaying the arrival of real benefits for the users even more. Finally, delaying would mean less testing, leading to more bugs and more delays.