Jump to content

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

From KDE Community Wiki
← Older edit
Make benefits in one sentence less techy
Cmollekopf (talk | contribs)
130 edits
 
(4 intermediate revisions by 2 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 lets you sync data data with many different online services, makes it easy for your applications to interact with your central store of events and contacts and reduces memory use by loading data only for use by many applications.
* Synchronise with Google Calendar.
* Synchronise with Nokia's phone calendar.


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


KDE PIM Messaging
==The Migration towards an Akonadi based PIM Suite==


===Status as of July 2010===
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.
* "normal usecases" are safe already
* This is the old kmail on top of new infra
Kontact and the rest of the KDE PIM suite have been ported to the Akonadi groupware cache. The new Kontact is a straight forward port of Kontact as we know it from KDE SC 4.4, but it has undergone large infrastructural changes. The current status of the Akonadi-based KDE PIM can be described as: Kontact itself is largely stable and feature-complete, it is assumed to be safe for "normal" use-cases. The KDE PIM team would like to invite thourough testing now in order to realize a fully stable and well-working release of KDE PIM. This stable release is expected to happen in Q3 or Q4 2010, based on the results of the testing reports.
When released, KDE PIM will be stable. Until the stable KDE PIM release based on Akonadi, monthly betas will be released. We would like to ask people to try using it and to get reports about problems. The KDE PIM team is fully committed to fixing issues that crop up. Especially important is the testing of migration scenarios at this stage. The focus is now on polishing the application and ironing out problems. Data loss at this point is highly unlikely. The main issues remaining are "weird" and "legacy" email setups and very large collections. "Normal use-cases" are safe at this point.


===Migration===
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.
The KDE PIM team is paying special attention to the migration process from previous versions of Kontact and its applications. The migration strategy works in two ways:
* Test and fix as many migration scenarios as possible
* Make it easy to roll back to the traditional kontact (from 4.4)
As an extra safety-net for your data, backup your $KDEHOME, for example ~/.kde or ~/.kde4. Then install the Akonadi-based KMail, the migration process should start automatically.
testing migration is especially important


====Rollback===
===Upcoming Features and Improvements===
In order to roll back, install the traditional Kontact, and use that:
* 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.
* data loss is very unlikely, issues are weird setups
* Exchange support is within reach now (legwork done by the Samba team)
* the more email you have, the better
* Fast virtual folders will come to full potential
* migration uses a *new* config, so rolling back is easy (status flags / tags between migrating and rolling back might be lost)
* Nepomuk features to link emails and contacts (and other semantic resources)
* test data migration with weird, legacy setups
* Clients for other platforms: KMail mobile, KMail on Windows
Please test the migration process and tell us your experience.
* 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.
 
===Distro Communication===
* 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 - also in 4.4
 
===Regressions===
* Performance & Resource usage: takes polishing (numbers vary wildly based on use-cases though)
* Memory: Virtuoso + MySQL costs more memory, likely more disk space
* KMail starts faster, but slower if Akonadi is not yet running
* UID+ required, otherwise IMAP won't work (many servers support it, but don't report it working), workarounds for GMX, GMail are already in
* Does Google IMAP work? (sebas: test)
* On-server filtering for POP3 not yet implemented, no timeline (unlikely to have many users)
* attachment loading on-demand not yet implemented (was only available in online IMAP anyway)
* server-side IMAP searching doesn't work, searching goes through Nepomuk
* http://thomasmcguire.wordpress.com/2010/05/14/akonadi-meeting-and-the-kde-sc-4-5-release/
 
===Current Advantages over 'traditional' Kontact===
* More scalable (mega folders work better in kmail2 than in kmail1)
* Syncing IMAP is magnitudes faster (there is still room for optimization)
* PUSH IMAP works for the Inbox, support for arbitrary folders is coming up
* full text search in emails is faster, and handled out of process (TODO: numbers)  
* Tag folders are as fast as others, don't block GUI
* Virtual folders based on SPARQL queries from search dialog
* see also: Thomas' presentation in Gran Canaria
* Annotating, tagging emails, virtual folders based on these tags
* Other apps start using Akonadi data (e.g. Plasma calendar)


===Quality===
===Information for Distro Packagers===
** hard to fix crashes are easier to fix now (such as IMAP threading problems), gone completely, or less severe due to process-separation of the components
* 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===
===Groupware Support===
The following groupware servers can be expected to work with Akonadi-based Kontact components:
The following groupware servers can be expected to work with Akonadi-based Kontact components:
* Kolab,
* OpenXchange (not Exchange),  
* OpenXchange (not Exchange),  
* Scalix,  
* Scalix,  
Line 110: Line 86:
* 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.
* 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.


===Upcoming Features and Improvements===
==FAQ==
* 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.
* I don't like Akonadi. Can I not use Akonadi?
* The whole PIM infrstructure is more robust
** 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.
* Going forward more other apps can access PIM data
* How/where does Akonadi store my data?
* Adding support for new resources is easy, adding support for more data types is easy
** 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.
* Exchange support is within reach now (legwork done by the Samba team)
* Is Akonadi part of this whole semantic desktop thing?
* Support for popular web services: Facebook data in Akonadi, LinkedIn contacts, ...
** 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.
* Fast virtual folders will come to full potential
* Why not delay Akonadi integration?
* Nepomuk features to link emails and contacts (and other semantic resources)
** 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.
* Clients for other platforms: kmail mobile (TODO: link / screencast?), KMail Windows
* Fancy Plasma stuff (e.g. Lion Mail, Calendar integration is even already there)
* Native caching on a per folder cache policies, etc.
* Finer-grained control over caching attachments using Disconnected IMAP, e.g. per folder
 
 
 
 
==Questions questions==
(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).
* Akonadi works with Nepomuk, in that it feeds Nepomuk with certain information about it's data.
* Why not delay Akonadi integration? 3 main reasons:
** 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
** Delaying would mean it would get tested less, which in turn means even 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"