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.
New Kolab-Resource that derives from the IMAP-Resource
- By: Christian Mollekopf
- Planned for: 4.14
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:
- improved performance: we can convert the objects directly inline, which saves processing power.
- we have one configuration per account (as opposed to the kolabproxy), because each resource is only responsible for one account, allowing me to get rid of the per account configuration hacks in the kolabproxy.
- A kolab account no longer requires two configuration dialogs, and the dialog can probably be simplified for kolab. (at least by default we only require server + login + password).
- The groupware folders no longer need to be hidden in the email client because they are not created anymore
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.
Job-based Resource interface
- By: Dan Vratil, Christian Mollekopf
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:
- no more AgentBase::Observer - we can add new new "tasks" withouth having to create another ObserverV42
- possible paralellization - multiple jobs can be running at the same time, speeding up sync for instance
- much nicer and easier-to-use API
- no more asserts because resource implementation called taskDone() when no task was running, etc....
- we introduce this as ResourceBaseV2 and deprecate ResourceBase
- resources are slowly ported to ResourceBaseV2
- initially the current ResourceScheduler can be used without almost any modifications
- in time we can introduce pararellization of tasks
- base jobs: RetrieveItemsJob -> resources implementation reimplement the jobs to provide the actual functionality
- implementations are registered to resource base ( registerJob<ImapRetrieveEmailsJob>() )
- Or the resource injects a ResourceTaskFactory that creates the jobs, or would that again result in the ObserverV42 problem?
- ResourceBase starts the Job like if it was dispatching a task