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).
Transition to frameworks, kdepimlibs first, rest will follow later. See http://community.kde.org/Frameworks/Akonadi
I want to introduce a new method of delivering change notifications from Akonadi server to clients inspired by IMAP IDLE extension.
Even with batch notifications and server-side notification filtering, Akonadi is still flooding DBus with large amount of change notifications. When a notifications is delivered to clients' Akonadi::Monitors, they need to query Akonadi for the actual item, which generates additional IO/CPU load and slows down the process.
Instead of DBus notifications, each Akonadi::Monitor would open a dedicated session, called IDLE session and push it's notification filter configuration to the server. The Akonadi server would then send change notifications via this session instead of using DBus messages. Unlike with DBus notifications, when additional roundtrip from Monitor to Server is needed to request the actual changed Item, Akonadi IDLE notification will, in addition to change description, already contain the actual Item.
This will make a use of the fact, that Server knows and has the Item (or Collection) at the moment when notification is generated, so it can easily serialize it (once) and send it to all interested parties.
I expect notable performance improvements and decrease in database load. The protocol-based "notifications: are also easier to extend, unlike DBus messages, which would solve our problem with having to introduce a new NotificationMessageVX every time we need to add something.
I want to move change recording from Agents to the Akonadi server. This feature depends on Akonadi IDLE and paves the path for addition features, like on-demand start/stop of Agents.
Currently each Agent records change notifications into it's own file. This duplicates some data (not much, but still) on the disk, but also generates a lot of IO, because we need to sync() it every time, even when the notification stays there just for a brief moment. I propose we store the change notifications on the Akonadi server, which already has a storage suitable for them, but also sees the "bigger picture" of all Agents available and can optimize accordingly.
Additionally, with server-side change recording, we can shut down an Agent when it's not used or usable (think for instance IMAP resource when network connection is not available) and still record all it's notifications on the server, then dispatch them once the Agent is usable again. This on-demand start/stop of Agents however, is a different task/topic, which will probably not be implemented in time for 4.14 (probably a KF5 topic)
Implementation of server-side change recording builds on top of Akonadi IDLE. The IDLE command will be extended to provide means for Akonadi::ChangeRecorder to enable/disable/suspend/resume change recording as well as request pending notifications from the server.
How the notifications will be stored on the Akonadi server has yet to be determined.
I want to add a new tab in the event create/edit dialog to add resources to an event like cars,beamber,rooms etc.
Currently kmail only knows about other persons as attendees for a event, but for many events it is nessesary to book also rooms, cars. etc. This should be done with another tab in the create/edit dialog of events. The first impementation would only support kolab servers, but should also usable with a own LDAP Server and a service for freebusy files.
I plan to replace the current calendar/folder selection widget with a new design that scales better with a lot of folders.
The current calendar selection quickly gets very complex with many calendars, and looking at a single calendar involves disabling all currently selected calendars, and enabling the one you want to see, which doesn't scale.
The new version addresses this in three steps:
To additionally unclutter the view, the selection will display all shared calendars of a person under a "Person"-node in the treeview. This way you only get one entry per person instead of one per folder by default, while still having access to the individual calendars when expanding the node.
The imap and kolab resources should synchronize the server-side subscription state with the local subscriptions, and synchronize all folders by default.
Currently, the imap resource filters the retrieved mailbox-list by the subscribed folders. All these folders are then subscribed to locally by default, with the additional option of unsubscribing some of them.
I want to change this to downloading all mailboxes, and synchronizing the server-side subscriptions with the local subscriptions (if server-side subscriptions are enabled). The subscription state would then also be considered for downloading data, so a full sync of a disconnected imap account would only download the data the subscribed folders.
The important advantage is that we can use the unsubscribed, but locally available folders to temporarly download data. That way you can have offline-imap folders, while still being able to i.e. access shared folders as online-imap. It also makes it fairly easy to use the local folder list for autocompletion.
In order to implement this I will need to make the Akonadi::SubscriptionJob public API.
A mechanism to temporarily include an otherwise disabled collection in a single application.
For the new calendar selection I need to be able to temporarily include otherwise disabled collections. This should make them available from within the application only (not from others), and the collection should be removed again once it is no longer referenced.
This feature will allow for "on-demand" loading of collections, so it is i.e. possible to temporarily look at an archive email folder without including it in the synchronization.
As a first usecase this will be used to temporarily load calendars in the new calendar selection.
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).
Envelope should contain
=> Everything that is required to display the event in the calendar view.
All calenderviews are heavily using Akonadi:Item nearly everywhere to share calender items. This makes it hard to use the calenderviews for events, that are not available inside akonadi. Think about freebusy data or having the possibily to sneak into an calender, that you don't want to add to akonadi. I done most of the work for agenda view and mostly the akonadiitems are not needed and can be replaced by KCalCore::Incidence.
If there are calender data not available inside akonadi, we should also be able to show multiple calenders insode one calendar view.
I done the work for agenda view at a local branch. Mostly the akonadi items are not needed and can be replaced by KCalCore::Incidence. Ping me if you are interessed in the branch. Hopefully i find time to merge it to master in November. Sandro (talk) 08:47, 18 September 2014 (UTC)