Promo/Guidance/Specific KDE Technology/Akonadi: Difference between revisions
No edit summary |
(update with info from thread on kde-pim list) |
||
Line 2: | Line 2: | ||
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. | 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== | |||
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. | |||
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. | |||
===Benefits in one sentence=== | |||
"Akonadi will centralize synching and caching of groupware data, deliver wider support for | |||
groupware servers and makes handling groupware data, such as contacts, calendaring and | |||
email more efficient by sharing it across applications." | |||
==Memes== | ==Memes== | ||
===do cool things with Akonadi TODAY=== | ===do cool things with Akonadi TODAY=== | ||
* | * You can connect KDE Groupware apps with Gmail, have your contacts imported (SC 4.4, still somewhat limited). | ||
* KDE PIM 4.5 will be able to connect to most calendar servers out on the web | |||
=== | ===What will be possible=== | ||
* | * 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=== | ===It solves real world issues=== | ||
* EXAMPLES of real world issues solved by Akonadi | * 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 | ===issues it still might have that might bite you (price of progress)=== | ||
* 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. | * 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. | ||
* 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== | ==Questions questions== | ||
(what Akonadi is and is not) | (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: | |||
Akonadi works with Nepomuk, in that it feeds Nepomuk with certain information about it's data. | ** 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 |
Revision as of 16:26, 2 June 2010
Akonadi communication strategy
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
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.
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.
Benefits in one sentence
"Akonadi will centralize synching and caching of groupware data, deliver wider support for groupware servers and makes handling groupware data, such as contacts, calendaring and email more efficient by sharing it across applications."
Memes
do cool things with Akonadi TODAY
- You can connect KDE Groupware apps with Gmail, have your contacts imported (SC 4.4, still somewhat limited).
- KDE PIM 4.5 will be able to connect to most calendar servers out on the web
What will be possible
- 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
- 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)
- 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.
- 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
(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