Contents
Mono Plugins
Although 2.2 has the capability for Mono plugins, most of the work needs to be done manually. Some lifecycle management needs to be added to the mono plugin driver, similar to the e-plugin-lib-init system, enable/disable of plugins, etc. But the bulk of the work will be providing useful-enough bindings to do real work.
External Mail Access
How to have other applications access email and/or mail resources. The easy approach is simply to add some corba interfaces to the Mail component to allow some of these operations; based on stream interfaces. The more complex one is to move mail access and storage into eds. The former is probably more practical at this stage, and with careful design could be a first-step of the latter idea.
The main focus in 2.4 will be to address the problem of sending email, as this is the main requirement of external applications.
Another area is for external applications to interact with/control the main user interface of Evolution. e.g. viewing or replying to specific emails. This should probably be done by extending the mail-component object to provide these functions, and for the mail component object to be addressable from CORBA more directly.
API consolidation for shared folders/acls
ACLs and Shared Folder stuff is currently done in a per-provider way. May make sense to provide a common api for these operations so it can be more easily accessed from the main application. This would let the same features be accessible for IMAP where they are available, too.
The best approach will probably be to canonicalise all capabilities into an extensible list that the front-end can use. A study must be made of IMAP, Groupwise and Exchange ACL capabilities.
For shared folders, there may be less ability to merge the requirements of all backends. If this is the case they should be implemented more using plugins. A store namespace mechanism may aid in implementing shared folders also, although the store could also just do that internally.
Plugins
Would be nice to have pluggable filters and extensible filter UI/backends, e.g. for server-side filtering.
Importers should be re-designed to be easier to implement, and converted to eplugins.
EPlugin 'qualifiers' need to be extensible. That is, the flags which enable/disable menu items and the like are currently hard-coded. This should be extensible for each plugin.
The C API needs to be exported appropriately for external plugins. i.e. install some of the various currently-internal header files.
Miscellaneous
(not likely to make 2.4)
ECalComponent to be fleshed out and made stand-alone, rather than relying on buggy libical.
Calendar model view controller design is poor and needs fixing.