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

From KDE Community Wiki
(update with info from thread on kde-pim list)
 
(6 intermediate revisions by 4 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.


Akonadi is complex, low-level and does not seem to have immediate benefits - the memes on this page can help communicate what Akonadi is good for to counter the 'bloath' and 'empty promises' arguments.
==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 IS akonadi==
===What can Akonadi do right now?===
Essentially, Akonadi is a framework that can understand and use email, calendaring and contact information from different sources. One benefit of this structure is that Akonadi can reduce system overheads - open up an address book once and share it across applications rather than each application opening up the same address book many times.
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.


Another benefit is relatively easy coordination of data on different devices - making it easy to share, backup, and synchronize between your computer, phone, and the internet.  For example, Akonadi can already synchronize with Nokia's phone calendars, and can access Gmail's contacts and Google Calendar, although those options are currently (KDE PIM 4.4) less evolved.
However at this point in time, Akonadi can:


===Benefits in one sentence===
* Connect KDE Groupware apps with GMail and have your contacts imported.
"Akonadi will centralize synching and caching of groupware data, deliver wider support for
* Synchronise with Google Calendar.
groupware servers and makes handling groupware data, such as contacts, calendaring and
* Synchronise with Nokia's phone calendar.
email more efficient by sharing it across applications."


==Memes==
===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.


===do cool things with Akonadi TODAY===
===Possible problems faced by users===
* You can connect KDE Groupware apps with Gmail, have your contacts imported (SC 4.4, still somewhat limited).
* 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.
* KDE PIM 4.5 will be able to connect to most calendar servers out on the web
* 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)


===What will be possible===
=== Possible innovations brought by Akonadi ===
* access to data from everywhere, seamless
** You can access e-mails and calendar events from a local file, from an IMAP server, GMail/GCal, phone or palm pilot, or a network file share all in the same application.
* Synchronize with anything.
** Synchronize this data with all kinds of applications and devices
* merge data. Having data from Facebook, linked-in, Gmail, hotmail and notes all in one stream – new, innovative apps bringing all this information together can be written easily.
* You won’t have to run any KDE Groupware app to have Akonadi work – it can sync and do it’s thing in the background, all the time.
* Akonadi will make it easier to connect to services
** As Akonadi’s modular design makes it easier to write connectors for it (connectors gather data for the user from other services like Facebook or Gmail) there will be more of them. Already quite a few external developers are working on cool connectors. This includes syncing with phones and other devices!


===It solves real world issues===
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.  
* EXAMPLES of real world issues solved by Akonadi
* Accessing data from other applications
** 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 (in development). Or imagine an invoice app sending mails by itself instead of having to call upon KMail for this.
** another use would be to drag and drop groupware things to your desktop (plasma) and have them easily accessible there, live updating once something happens. Think email(threads), chat logs, shared notes etc
* most issues are low in the stack, things developers have had to deal with. Akonadi is far easier to work with, and while it might take some time to get it implemented in the ‘old’ applications, it will make those apps easier to maintain and improve.
* Performance. Currently, each KDE app which must access for example address book information must load KAddressbook. It can easily be loaded 5-6 times in memory. Akonadi makes this unnecessary, saving memory.
* Scalability. Akonadi supports pluggable back ends (currently MySQL is implemented). Having huge numbers of mails is no problem for Akonadi – while other solutions will struggle when confronted with more than 50.000 mails… With modern storage you don’t have to delete email anymore so such numbers are less and less extreme.


===issues it still might have that might bite you (price of progress)===
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:


* Packaging issues galore: packagers are not yet familiar and dependencies are new and sometimes still immature. This creates issues. In time, the out-of-the-box experience will get better.
[[Image:Plasma calendar.jpg|thumb|center|200px|Plasma Calendar]]
* Akonadi sometimes complains a bit too much, this is being worked on
* During migration it is possible some settings like account settings are lost. However, the new KMail in KDE PIM 4.5 has a much improved account wizard which automatically configures most email accounts out there.


==Questions questions==
==The Migration towards an Akonadi based PIM Suite==
(what Akonadi is and is not)
 
* It is important to note that 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).
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.
* Akonadi works with Nepomuk, in that it feeds Nepomuk with certain information about it's data.
 
* Why not delay Akonadi integration? 3 main reasons:
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.
** Delaying would mean maintaining several versions of the KDE PIM apps, wasting resources
 
** Delaying would mean developers don’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
===Upcoming Features and Improvements===
** Delaying would mean it would get tested less, which in turn means even more delays
* 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.

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.
Retrieved from "https://community.kde.org/index.php?title=Promo/Guidance/Specific_KDE_Technology/Akonadi&oldid=18499"