This page is meant to collect various planned features/enhancements. For the release planning all features that you want to implement should be listed in http://techbase.kde.org/Schedules/KDE4/4.13_Feature_Plan (you can for instance just link here).
Note that this page is strictly for developers, and NOT a wishlist.
This section is for features where you have concrete plans for implementation (doesn't have to be in the next release). A short description, the approximate timeline if you know already (e.g. for version X), and the reason why the feature is needed would be interesting.
I plan to replace the kolab proxy with a new resource that derives from the imap resource (so no additional agent anymore). Each imap resource would have two root collections, one for email and one for groupware data.
The primary reason is to reduce the overall complexity of the design, I expect the new resource to be easier to debug (because it's mostly the same codebase as the imap resource) and to be less error prone (because it's one less level of indirection). Other reasons are:
It should be possible to request items by certain properties, such as a start and end date of an event, so not all items need to be loaded into memory.
One of the largest performance limitations is that we currently have to load all items into memory in order to be able to select the ones we're interested in, since the akonadi server doesn't know the payload. We therefore require indexes of certain interesting properties that allow us to query by these properties.
The problem is very similar to search, so it can probably be solved similarly. I'm not sure whether the indexing should happen in the baloo indexer, or in a preprocessor, since IMO fulltext indexing can be "eventually consistent" (5min delay wouldn't be a big problem), where these indexes are required to make the item available to the application (the event will not appear before the corresponding index and open query is updated). Applications would "search" for the item-set, that would be exposed as virtual collection. So the calendar would i.e. search for "events of week 42", for which it would receive an id of a virtual collection that it can monitor. That will give the calendar only the event's it requires for display, including notifications for the range it's interested in only. As the user scrolls in the view, the range query needs to be modified and updated accordingly.
We want to be able to create relations between items in akonadi, so we can for instance relate a note to an email.
A generic mechanism is needed to associate items, other than the existing tags (which are visible and have a name, etc.), and collections (similar to tags). The relations mechanism should provide 1:1 relations with a type. Usecases: note-email, todo-email, ... (full mesh).
List in this section ideas that you think should be implemented, but you currently have no plans of working on in the near future. It will hopefully allow us to share some of the ideas that are currently only existing in one or the other head.
The idea is to replace the current ResourceBase interface with a job-based one. Each task (retrieveItems, itemChanged, collectionAdded, ....), is a job, that can be implemented by each resource implementation.
This will result in a simpler interface (since the resources are doing an async operation anyways), make it easier to support parallellism of tasks, etc.
Other benefits are:
While creating ResourceBaseV2 we should also make it testable. See the IMAP-Resource how this could work. Ideally all akonadi related jobs are part of the respective job/task interface, which makes it possible for the tests to test each individual job without requiring an akonadi server.
Extract and store certain data from events into PLD:ENVELOPE part. Allows MemoryCalendar to retrieval all ENVELOPEs and then fetch PLD:RFC822 only for events that are relevant to required data/time.
It first needs to be verified how large the impact of this would be, since calendar data is relatively small (except for attachments).