m (→Tutorials) |
Neverendingo (Talk | contribs) m (Text replace - "<code cpp>" to "<syntaxhighlight lang="cpp">") |
||
Line 602: | Line 602: | ||
A very common problem of resources based on Akonadi::ResourceBase are "unguarded exit paths" from one of the methods you have reimplemented there. See the following example: | A very common problem of resources based on Akonadi::ResourceBase are "unguarded exit paths" from one of the methods you have reimplemented there. See the following example: | ||
− | < | + | <syntaxhighlight lang="cpp"> |
void MyResource::retrieveItems( const Collection &collection ) | void MyResource::retrieveItems( const Collection &collection ) | ||
{ | { | ||
Line 615: | Line 615: | ||
The following example does it correctly: | The following example does it correctly: | ||
− | < | + | <syntaxhighlight lang="cpp"> |
void MyResource::itemAdded( const Akonadi::Item &item, const Akonadi::Collection &parent ) | void MyResource::itemAdded( const Akonadi::Item &item, const Akonadi::Collection &parent ) | ||
{ | { |
The following list contains the things which need to be done for Akonadi.
Note: The person noted in the "Contact" column is not necessarily the one implementing that feature, but the one who can tell you what to do and how to help, i.e. you can also contribute to those tasks ;-)
There is also a more detailed page about bugs and missing features of things that are currently ported here.
Urgent tasks that need to be finished for the KDE 4.1 release (May 19th):
Status | Item | Description | Contact |
---|---|---|---|
DONE | Item streaming in ItemSync/ResourceBase | As discussed in Osnabrueck | <Tom/Volker> |
DONE | Payload serialization format versioning | see below
tokoe@kde.org |
<Tobias> |
DONE | API for additional item parts | As discussed in Osnabruck | <Volker/Tobias> |
DONE | Infrastructure for showing additional dialogs from agents/resources | As discussed in Osnabrueck | <Tom> |
DONE | Allow to limit ItemFetchJob to current cache content | Prevents search index feeder agents from downloading all remote data | Volker <vkrause@kde.org> |
DONE | Fix API for item/collection modifications | See Osnabrueck meeting notes for details | Volker <vkrause@kde.org> |
DONE | Plugin Versioning | For serializer plugins, also check using Qt plugin stuff instead of the libkdepim plugin framework | Tobias <tokoe@kde.org> |
DONE | Tray app | small app to control the server and have a something that can report errors | Toma <tomalbers@kde.nl> |
DONE | Backup support | Dump & Restore database contents, also useful when upgrading to a newer database version | <tomalbers@kde.nl> |
DONE | Akonadi Artwork | Icon for the tray app | Toma <tomalbers@kde.nl> |
That's the stuff we want to have in 4.2, very roughly ordered by priority. Releases are scheduled for early January 2009.
Status | Item | Description | Contact |
---|---|---|---|
DONE | Server error reporting | Helpful error message when the server cannot be started or if there is some other problem communicating with it. | Volker <vkrause@kde.org> |
DONE | KResource migration tool | For KABC and KCal resources, setting up Akonadi <-> KResource bridges where needed | <Volker> |
DONE | KResource bridges | Basically finished, needs more testing | <Kevin> |
DONE | Distribution Lists | Serializer Plugin and resource support | <Tobias,Kevin> |
DONE | Complete iCal resource | error handling, robustness, legacy formats, file montitoring | <Volker> |
DONE | Complete vCard resource | same as iCal + binary legacy format | <Bertjan> |
DONE | Item size | Needed by Mailody | <toma@kde.org> |
DONE | LINK/UNLINK commands | Managing item references in virtual collections | Volker <vkrause@kde.org> |
DONE | Akonadi Testrunner | Running tests in a self contained Akonadi setup | Igor <igor_trindade@yahoo.com.br> |
DONE | Remote file support for iCal/vCard resources | Replaces net/remote KRes resources | <Bertjan> |
DONE | Solid integration | Switch online/offline state in ResourceBase automatically | <Bertjan> |
Stuff that went into KDE 4.3 and Akonadi server 1.2.
Status | Item | Description | Contact |
---|---|---|---|
DONE | Fix unit tests | Make unittests work without destroying the production database | <Igor/Volker> |
DONE | Filesystem Backend | Store content data in files instead of the database, transfer filehandles instead of data to the client | <Andras> |
DONE | IMAP resource | <Kevin> | |
DONE | Kolab proxy resource | <Andras> | |
DONE | RID based operations | Item/collection retrieval and modification based on remote identifiers | <Volker> |
DONE | Microblog Support | Type library, serializer plugin, identi.ca/twitter resources | <Tom> |
DONE | ResourceBase::collectionsRetrievalDone is missing | I'm working around by calling collectionsRetrievedIncremental() with empty collection lists | <Volker> |
The following is being worked on for KDE 4.4 and Akonadi server 1.3.
Status | Item | Description | Contact |
---|---|---|---|
DONE | Port KAddressBook | Replace with KContactManager | <Tobias> |
DONE | Resource testing framework | Automated, shareable tests for resources | <Igor/Volker> |
IN PROGRESS | Review change notifications | See the various discussions about shortcomings in that area | <Volker,Steve> |
DONE | Collection statistics for sub-trees | Provide a CollectionStatus object covering the full sub-tree in the model, allowing accumulated unread counts etc. | <Kevin> |
DONE | Favorite Folder Model | see current KMail | <Kevin> |
DONE | Batch jobs for modifying/deleting collections/items | it would be great to have jobs which perform operations on several entities in one go | <Volker> |
DONE | Collection streaming support in ResourceBase/CollectionSync | Similar to what is available for items already | <Volker> |
DONE | MBox resource | <Bertjan> |
Stuff that is planned for inclusion in 4.5, partly already available in the akonadi-ports branch.
Status | Item | Description | Contact |
---|---|---|---|
IN PROGRESS | Port KOrganizer | Port from KResource to Akonadi | <Frank/Sebastian> |
DONE | Account creation wizard | as discussed in Berlin, see below | <Volker,Laurent,Tom> |
IN PROGRESS | KMail port | KMail using Akonadi | <everyone> |
IN PROGRESS | Remote Search | Delegating searches to resources, see below | <Volker> |
This stuff is currently not considered for 4.5 due to lack of resources. Of course it will be added nevertheless if someone implements it. The list is completely unsorted.
Status | Item | Description | Contact |
---|---|---|---|
TO DO | Error reporting | Akonadi::Job basically has only one error code: Unknown | <Tobias> |
IN PROGRESS | Port KNotes | File resource, serializer plugin, KNotes application, Kontact plugin | [mailto: <>] |
TO DO | Batch job to retrieve a set of items from Akonadi | Those items don't belong to the same collection, rather they are located in different collections | [mailto: <>] |
TO DO | CollectionFetchJob/ItemFetchJob should be able to retrieve entities by flags/mimetype |
This is problematic with change notifications, as they have to know about the filtering with the \Seen flag as well. This type of filtering would be possible with full Nepomuk interface though. We don't want yet another query language here. The plan is to fix the nepomuk agent and use that as semi-public interface for now. |
[mailto: <>] |
TO DO | Nepomuk integration | Generic Item tag/rate/comment, etc. | <Tom> |
TO DO | Sync collection tree after creating setting up a resource | see AgentInstanceCreateJob | [mailto: <>] |
TO DO | Support standard commands for QUndo framework | [mailto: <>] | |
TO DO | Conflict detection in resources | See Osnabrueck meeting notes for details | [mailto: <>] |
IN PROGRESS | Action framework | see below | Volker <vkrause@kde.org> |
IN PROGRESS | Fix API docs | The libakonadi move as well as the huge API changes following it broke lots of the docs technical and content-wise, see below | <Tobias> |
IN PROGRESS | Migration | Data and settings from pre-Akonadi times, see below | [mailto: <>] |
IN PROGRESS | Extended notifications | Item change notification do not yet include their source collections (real and virtual) | [mailto: <>] |
TO DO | Alternative for Akonadi::ResourceBase | Not using the scheduler to avoid the serialization of operations, see RSS resource. (This will get very complicated. Maybe use a proxy ResourceBase for this, which is thread-pooled?) | [mailto: <>] |
Overview on the current state of support for various types:
Type | Serializer | Multipart Support | Models | Views | Resources | Notes |
---|---|---|---|---|---|---|
yes | partial | MessageModel, MessageCollectionModel, threading proxy model | ? | maildir, IMAP | threading agent | |
News | yes (1) | partial (1) | (1) | (1) | NNTP | |
Contact | yes | no | ContactModel | - | vCard, facebook, KRes | |
Events | yes | no | EventModel | - | iCal, KRes | |
Notes | no | no | - | - | - | not started yet |
Feeds | yes | no | Feeds, Items | ? | OPML | GSoC in playground/pim |
Bookmarks | yes | no | - | - | local bookmarks, del.icio.us |
(1) see Email
Status | Item | Description | Contact |
---|---|---|---|
TO DO | Share mail flag code | Standard actions, standard flag enum/constants, Nepomuk interaction | [mailto: <>] |
Status | Item | Description | Contact |
---|---|---|---|
TO DO | Todo proxy model | See KOrganizers To-Do view | <Bruno?> |
DONE | Subtype identification | See discussion on kde-pim mailinglist | <Kevin> |
IN PROGRESS | Agenda view | KOrganizer agenda view based on Akonadi | <Sergio,Kevin> |
TO DO | Month view | KOrganizer month view based on Akonadi | <Bruno?> |
TO DO | Timeline view | KOrganizer timeline view based on Akonadi | [mailto: <>] |
Status | Item | Description | Contact |
---|---|---|---|
DONE | KResource Akonadi bridge | for applications using KCal or KABC | Kevin <kevin.krammer@gmx.at> |
DONE | Akonadi KResource bridge | for data accessed through KCal or KABC resources | Kevin <kevin.krammer@gmx.at> |
TO DO | Expire Agent | [mailto: <>] | |
DONE | MBOX Resource | <Bertjan> | |
DONE | Extend IMAP Resource | <Kevin/Andras> | |
IN PROGRESS | POP3 Resource | <Thomas> | |
IN PROGRESS | RSS Resource | in akonadi-ports branch (Details) | <Dmitry/Frank> |
IN PROGRESS | Filter Agent | <Szymon> | |
TO DO | Search | [mailto: <>] | |
TO DO | History resource | [mailto: <>] | |
IN PROGRESS | Filter Rule GUI | Used by filters and searches | <Szymon> |
Resource status overview (this should list all resources existing in KDE3 or already under development for Akonadi):
Resource | Retrieve Collections | Retrieve Items | Change Collections | Change Items | Configuration | Notes |
---|---|---|---|---|---|---|
iCal | yes (4) | yes (1) (2) | no | yes | yes | remote file support, file watching with conflict handling |
vCard | yes (4) | yes (1) (2) | no | yes | yes | remote file support, file watching with conflict handling |
maildir | yes (1) (4) | yes (1) (2) | ? | ? | yes | |
mbox | no | no | no | no | no | not started yet, code exists in KMail |
IMAP | yes (1) (4)? | yes (1) (2) | no | no | no | code exists in kio_imap4 and Mailody, support for extensions: quota, ACL, annotations missing, what about Kolab and Scalix? |
NNTP | yes (4) | yes (2) | n/a | n/a | yes | Needs support for local collection names and collection hierarchy |
Local Bookmarks | ? | ? | ? | ? | (3) | Code in akonadi/resources |
OpenChange | ? | ? | ? | ? | ? | Code in akonadi/resources |
? | ? | ? | ? | ? | Code in playground/pim | |
del.icio.us | ? | ? | ? | yes | no | Code in playground/pim |
KABC | yes(6) | yes | no | yes | yes | |
KCal | yes(6) | yes | yes(7) | yes | yes |
Everything without migration support is implicitly converted to use the compat bridge currently.
KResource | Feature equivalent agent | Migration support | Notes |
---|---|---|---|
directory | vCard dir in development | ||
file | vCard file | 4.2 | binary format no longer supported, migrated to compat bridge instead |
groupdav | |||
groupwise | |||
kolab | |||
ldapkio | |||
net | vCard file | TODO | |
scalix | |||
slox | |||
xmlrpc |
KResource | Feature equivalent agent | Migration support | Notes |
---|---|---|---|
blog | |||
bugzilla | |||
groupdav | |||
groupwise | |||
kabc (birthday) | birthdays | 4.3 | |
kolab | |||
localdir | |||
local | iCal file | 4.2 | |
remote | iCal file | TODO | remote supports different URLs for upload and download, the iCal file agent doesn't, is this needed at all? |
featureplan | probably obsolete since we don't use the XML featureplan anymore | ||
scalix | |||
slox | |||
xmlrpc |
Ideas/notes etc. on various open issues in Akonadi.
Idea: Have something like KStandardAction for Akonadi that not only includes the representation of the action but also its state management and the actual operations. Like libakonadi that should be splitted into a generic, type-independent part and be extensible for type-specific actions. This will enable code sharing among many applications and guarantee consistent actions everywhere.
State management: watch selection models of a collection and/or item model.
Use KXMLGUI for context menus in standard views to allow easy extensibility with custom actions.
Generic actions:
The list is definitely long enough to make this worthwhile.
Ideas/missing features/bugs of the collection model/view:
Notes on how to keep long-term protocol, source and binary compatibility.
Notes/ideas/complaints about the Akonadi::ResourceBase API:
Smaller stuff that should be fixed before the ABI freeze and is not yet listed above:
Notes on the resource configuration wizard discussion.
Has been merged for Akonadi server 1.3. We still need a volunteer for continuous testing and maintenance though.
Got their own page by now:
The current plan is to put some parts of KMail into a stand-alone library, independent of KMail. This increases code reuse (for example, the message composer could be shared with Mailody) and makes the code a lot easier to maintain and to port to Akonadi.
Status | Item | Description | Contact |
---|---|---|---|
TO DO | Bodypart formatters | [mailto: <>] | |
DONE | Reader Window | <Andris> | |
DONE | Composer: Message Composer | <Constantin,Leo> | |
IN PROGRESS | Composer: GUI Window | <Constantin> | |
DONE | Queue Manager for mailtransport | <Constantin> | |
IN PROGRESS | Templates: Core | <Leo> | |
TO DO | Templates: GUI | [mailto: <>] | |
TO DO | Port KMCommands | [mailto: <>] | |
DONE | Port away from KMMessage and KMFolder* everywhere it is left | An idea might be: wrap KMMsgBase/KMMessage inside a reference counted Message class. Insulate everything else from it by wrapper functions. KMFolder should be easier... | <all> |
IN PROGRESS | Migration application for index and other config | <Casey> | |
TO DO | Port MDNs | [mailto: <>] |
Sort of related so the stuff above but with a scope for all of KDE PIM and beyond.
Status | Item | Description | Contact |
---|---|---|---|
TO DO | Share identity config GUI parts | eg. the signature configuration widget | [mailto: <>] |
DONE | Mailtransport Agent | Global shared outbox, central mail sending instance | <Constantin> |
TO DO | Recently sent to support in mailtransport | related to above, based on Akonadi/Nepomuk | [mailto: <>] |
IN PROGRESS | Composer engine | Shared stuff for KMail/KNode/Mailody: Crypto, editor, editor actions, attachment model, message assembly, etc. | <Constantin,Leo> |
This FAQ primarily deals with technical and design questions, if you have questions about using Akonadi (such as "I get error X when starting Akonadi"), please refer to userbase.kde.org/Akonadi.
~/.config/akonadi/
Akonadi merely acts as a cache for your data, the actual content stays where it has always been, .ics/.vcf/MBOX files, local maildirs, IMAP- and groupware servers. There is only a limited amount of data stored exclusively in Akonadi:
~/.local/share/akonadi/
There are three different parts of source code:
The documentation is mainly in the code itself, in the form of doxygen comments. You can find the generated documentation on [api.kde.org api.kde.org], for example:
So far only MySQL. There is some work on PostgreSQL support going on though. Basically, every database that is supported by QtSQL can be used, requiring minimal changes in the code at most. However, not all of them provide the features needed by Akonadi (see next two questions).
We tried. Really. It can't handle the concurrent access very well, in the best case this means very slow operations, but we've also seen deadlocks and failing transactions. Once that's fixed in sqlite, adjusting Akonadi to use it again instead of MySQL is no problem.
We tried that as well, there are two reasons for not using it: No support for the InnoDB engine (which we need for transaction support) and poor availability (only OpenSUSE provided usable packages, needed a patched QSQL driver).
No. Akonadi starts its own local MySQL server (unless configured otherwise, see next question). All you need is having the 'mysqld' binary installed at runtime (usually found in the mysql-server package of your distribution).
Yes, it can. You find the corresponding settings in ~/.config/akonadi/akonadiserverrc.
That does not work unfortunately. Akonadi does not store all relevant data in the database but also uses the file system for configuration and large payload data for example. Also, there is no mechanism to ensure multiple instances have exactly the same version and exactly the same agents and plug-ins installed etc., all of which would be necessary to work on the same database. Finally, there is no notification system to inform the other instances about changes which endangers consistency since the Akonadi server contains internal caches of data in the database. If you want multiple instances to synchronize, use a groupware server (not as bad as it sounds, Kolab for example works with many normal IMAP servers).
If you try this despite the warnings, be aware that there is no safety mechanism in place to prevent you from doing that and you will likely mess up your data in funny ways.
See section "Deployment Issues" above, we are aware of that and working on it. Some of these, like backup/restore are already implemented. But please be aware that most of this issues also existed before (eg. with KMail's custom binary indexes).
No. There has to be one Akonadi server instance per user. However, it is possible to use a shared database server.
No. Akonadi is not a groupware server. It's a local cache only.
EDS (Evolution Data Server) is limited to contacts and calendar data, Akonadi is type-independent. Especially, Akonadi is designed to also handle high-volume data such as email. Akonadi and EDS also differ largely in their access protocol on a technical level (Corba/D-Bus vs. local socket with IMAP-like protocol/D-Bus) and also on a protocol level (type specific vs. generic).
From the developers point of view, there is Akonadi::CollectionCreateJob for that, from the users point of view, most applications allow that, eg. Mailody or akonadiconsole.
However, there is one limitation: Top-level collections can only be created by resources, not by normal applications. The reason for that is that every object (collection or item) is supposed to have an owning resource, that is a resource that is responsible for storing and retrieving that object. There is an ongoing discussion to remove this restriction though.
So, if you want to create a collection eg. for testing purposes, add a resource first. Most Akonadi applications offer an option to do that, a module for KControl is planned as well.
The migration tool is controlled by standard KDE configuration file called kres-migratorrc.
Distributors or system administrators wanting to disable the automatism will probably want to that globally, e.g. by editing the installed default configuration file, or by using KDE's configuration hierachy and using a profile config between that and the user level.
The quickest way to deactivate it for one user account only is to use KDE's kwriteconfig tool to set the respective configration value with a simple copy&paste of the following command:
kwriteconfig --file kres-migratorrc --group Migration --key Enabled --type bool false
Please note that at some point KDE applications such as Kontact, KOrganizer, KMail will be using Akonadi directly, at which point migration either has to be enabled or performed manually.
As of KDE 4.4 (and its development releases and when building from SVN trunk) this already applies to KAddressBook and KMail's address book access.
Warning |
---|
If you already have applications natively using Akonadi, you of course can't disable Akonadi startup. KAddressBook (as of KDE 4.4 and its test versions), Mailody, KMail (as of KDE 4.4 and its test versions for address book related things) and KPilot are applications that are already based on Akonadi. |
Other applications, like KOrganizer, are not based on Akonadi yet, at the time of writing. Instead, they use the old KResource framework for storing contacts, calendars and notes.
During the KDE 4.2 beta time, these KResources were automatically migrated to Akonadi-based KResources, the so-called Akonadi compatibility resources. Therefore, applications like KOrganizer would use Akonadi indirectly through KResources, and therefore would start the Akonadi server when being started.
If Akonadi doesn't start up correctly for you, the following should help you to disable Akonadi startup and use your old KResources again.
First, disable automatic migration like described in the above FAQ entry. Then, open System Settings, go to the Advanced tab and open the KDE Resources config panel. There, you can configure which type of KResources are used for contacts, calendars and notes. If the migration to Akonadi was successful, you'll probably only see the Akonadi Compatibility Resource as an active resource, and all others disabled.
To disable Akonadi startup, enable your old resources again, then disable and delete the Akonadi compatibility resource.
Akonadi and OpenSync focus on different aspects and complement each other. Akonadi provides a unified way to access PIM data for applications and a framework to implement powerful connectors to varies data sources. OpenSync focus is on syncing two sets of PIM data.
An Akonadi plugin for OpenSync is currently under development, allowing to sync PIM data available through Akonadi with any other system supported by OpenSync, especially mobile phones.
More precisely, when should you use for your application specific data instead of eg. just using a local file directly.
Akonadi is especially useful when you need one the following:
However, if you are just looking for a simple way to store your application data without needing one of the above, using Akonadi usually means more implementation work for relatively little gain.
An empty, unused Akonadi database needs about 100 Mb of disk space. This is due to the MySQL InnoDB log files which work similar to a journal in a modern file system. These files are constant in size and independent of the actual data stored in Akonadi. The default size is optimized for performance on average desktop hardware where the use of 100 Mb of disk space is no problem. In other cases, such as multi-user systems or embedded devices, this default might not be optimal though.
The default size can be configured, globally or per-user. The global configuration file can be found in $PREFIX/share/config/akonadi/mysql-global.conf, the per-user file is in ~/.config/akonadi/mysql-local.conf and overwrites settings of the global file. In any of these files, you can change the settings innodb_log_file_size and assign it a smaller value than the default (64M).
For this setting to take effect you need to restart Akonadi. With older Akonadi versions (<=1.1.1) you might need to manually remove the InnoDB log files from ~/.local/share/akonadi/db_data for this change to take effect. The log files do not contain data after a clean shutdown and thus can safely be removed while Akonadi is not running.
An alternative approach especially for multi-user systems might be the use of a single, global MySQL server instance.
A very common problem of resources based on Akonadi::ResourceBase are "unguarded exit paths" from one of the methods you have reimplemented there. See the following example:
void MyResource::retrieveItems( const Collection &collection )
{
if ( someError )
return;
itemsRetrieved( myItems );
}
</code>
In case of an error you leave retrieveItems() without telling Akonadi::ResourceBase that you are done with the task. Therefore, it is assumed the requested item retrieval takes a bit longer (which is not uncommon for resources for remote backends, results typically come in in a result slot connected to a job class for example) and waits until you announce the task is finished.
The following example does it correctly:
<syntaxhighlight lang="cpp">
void MyResource::itemAdded( const Akonadi::Item &item, const Akonadi::Collection &parent )
{
if ( noNetwork ) { // transient error
deferTask( i18n( "Offline, will retry later." ) );
} else if ( item_not_valid ) { // permanent error
cancelTaks( i18n( "Got invalid crap, can't store that." ) );
} else {
// store the item here
Item newItem( item );
newItem.setRemoteId( my_new_remote_id );
changeCommitted( newItem );
}
}
</code>
The following methods require explicit notification that a task has been completed:
* retrieveX
* any method indicating changes, ie. itemAdded|Changed|Moved|Removed(), collectionAdded|Changed|Moved|Removed()
* any custom task scheduled with ResourceBase::scheduleCustomTask()
Refer to the API documentation of Akonadi::ResourceBase for the various ways to do that correctly, there are a few different ways, depending on the current task:
* Successful completion with convenience features, eg. changeCommitted(), itemsRetrieved() etc.
* Error cases with convenience features, eg. cancelTask(), deferTask()
* Only indicate completion, with everything else done manually, eg. changeProcessed(), taskDone()
To confirm a resource is affected by this problem, the "Resource Schedulers" tab of akonadiconsole is very useful (needs to be enabled in the context menu first, causes too much slowdown otherwise). It shows the state of the internal task scheduler of your resource, allowing you to spot stuck tasks.
== Information for Developers using Akonadi ==
References to information for developers using or extending Akonadi.
=== Tutorials ===
* [[Development/Tutorials/Akonadi/Application|Application Development]]
* [[Development/Tutorials/Akonadi/Resources|Resource Development]]
* [[Development/Tutorials/Akonadi/SerializerPlugin|Serializer Plugin Development]]
* [[Development/Tutorials/Akonadi/CreatingAccountWizardPackages|Creating accountwizard packages]]
* [[Development/AkonadiPorting|Application Porting]]
=== Documentation ===
* [[Projects/PIM/Akonadi/Testing|Akonadi Testing Framework]]
* [[Projects/PIM/Akonadi/Development_Tools|Akonadi Development Tools]]
* [[Projects/PIM/Akonadi/Firstrun|Akonadi Firstrun]]
* [http://api.kde.org/4.x-api/kdepimlibs-apidocs/akonadi/html/index.html Client Library API documentation]
=== Projects ===
* [[Projects/PIM/Akonadi/Bookmarks|Bookmark support based on Akonadi]]
* [[Projects/PIM/Akonadi/PortingStatus|Akonadi Port - List of Bugs and Features]]
=== Contact & Getting Involved ===
* #akonadi IRC channel on freenode
* kde-pim@kde.org mailing-list
* Google Summer of Code
** [[Projects/Summer of Code/2009/Ideas#KDE_PIM|Google Summer of Code 2009 Ideas]]
** TODO: add links for other years
=== Links ===
* [http://pim.kde.org/akonadi/ http://pim.kde.org/akonadi/]
== Akonadi Internals ==
References to information for developers of Akonadi itself (the above section is of course also relevant for you).
=== Documentation ===
* [[Projects/PIM/Akonadi/Release_Howto|Akonadi Release Howto]]
* [[Projects/PIM/Akonadi/Database|Akonadi Database Internals]]
* [http://api.kde.org/kdesupport-api/kdesupport-apidocs/akonadi/html/ Akonadi Server API documentation]
=== Meeting Notes ===
* [[Projects/PIM/Akonadi/Meeting2008-11|Halloween Sprint 2008]]
* [http://community.kde.org/KDE_PIM/Meetings/Osnabrueck_7 Osnabrueck 7]
* [[Projects/PIM/Akonadi/Meeting2009-04|Akonadi April Sprint 2009]]
* [[Projects/PIM/Meetings/GCDS_2009|GCDS/aKademy 2009]]
* [[Projects/PIM/Akonadi/Meeting2009-10|Akonadi October Sprint 2009]]
* [http://community.kde.org/KDE_PIM/Meetings/Osnabrueck_8 Osnabrueck 8]
* [http://community.kde.org/KDE_PIM/Meetings/Akonadi-2010-05 Akonadi/KDE PIM pre45 sprint 2010]
[[Category:PIM]]