Re: [Evolution-hackers] Evolution Future Roadmap

[David Malcolm <dmalcolm redhat com>]

On Wed, 2004-07-21 at 12:43 -0400, JP Rosevear wrote:
> I'd like to start laying down a road map for Evolution to give some
> direction to the hackers that work on Evolution after 2.0.
> 
> This plan is to to cover 3 versions after 2.0, coinciding with
> approximately 6 month releases cycles of GNOME, this is mostly core
> stuff and not absolute (for instance we'd put in other backends for
> opengroupware, exchange it, etc if they became available).  We want to
> list specific functional goals that are largish in nature.  A lot of
> smaller features will just end up as EPlugins.
> 
> Bring on the feedback.

Some thoughts inline below...

> 
> 
> Evolution 2.2 (Spring 2005)
> Mail
>       * IMAP rewrite to improve async server notification handling
>         (IMAP4 camel provider) 
>       * detaching camel from evolution 
>       * read/delivery receipts of messages via RFC
> Contacts
>       * supported fields handling (supported/not supported, required,
>         ranges allowed) so the editor can disable fields appropriately
> Calendar/Tasks
>       * our own libical implementation based on the vcard parser 
>       * detached instance support in the GUI and file backend 
>       * supported fields handling (supported/not supported, required,
>         ranges allowed) so the editors can disable fields
>         appropriately 
>       * use range of time (ie 10am for 1 hour) for time selection in 
>       * attachments to events/tasks

How about support for hierarchical tasks, so that one task can be a
child of another?

> EPlugin
>       * hook into any popup menu 
>       * hook into main menu's, based on current view and view
>         context. 
>       * hook into configuration pages 
>       * hook into in-line display of mail content, at the very least
>         for imip and the like. 
>       * mono wrappers to write plugins
Please keep any mono stuff optional.

> Groupwise
>       * proxy user access 
>       * shared folders 
>       * permission management 
>       * delivery and read receipt status tracking 
>       * retract and recall messages 
> Exchange
>       * integrate ximian-connector-setup functionality into the Evo
>         Acct Assistant for adding Exchange account 
>       * remove need for separate exchange component for public folder
>         handling 
>       * delivery and read receipt status tracking 
>       * open other user's entire mailbox 
>       * display pre-emptive password expiration warnings 
>       * display quota messages sent by Exchange Server Display folder
>         sizes 
>       * display Favorites folders 
>       * add/remove Favorites folders
> Other
>       * RTL support in GtkHTML 
>       * merge needed gal pieces into evolution 
>       * inclusion of exchange support directly in eds 
>       * loadable backend modules in eds 
>       * gnome-key-ring instead of e-password (e-password could be a
>         wrapper)
Excellent!

How do you feel about breaking out the UI, so that Evolution appears to
be four separate programs to the user?  Each component would be in its
own top-level window, and you'd use Alt-Tab to switch between the Email
and Calendar, rather than clicking on the buttons.

> 
> Evolution 2.4 (Autumn 2005)
> Mail
>       * camel plugins 
>       * server side rules
> Contacts
>       * default to using flat file backend 
>       * online/offline support for LDAP
> Calendar/Tasks
>       * decline/counter and counter support 
>       * comments when declining IMIP requests 
>       * online/offline support using cache for webcal
> EPlugin
>       * filter types, if camel filters can also be customisable
>         (needed for server-side rules) 
>       * pluggable junk stuff, although some of that might need camel
>         plugins instead. 
>       * event stuff, like 'message shown', 'folder opened', 
>       * backward hooks so you could do things like run a server which
>         interacts with internal data
> Groupwise 
>       * online/offline support 
>       * server side rules 
>       * delay delivery of mail until specified time 
>       * request reply of mail within a specified time frame
> Exchange
>       * online/offline support 
>       * server side rules 
>       * task delegation 
> Other
>       * unified account support to share connection information among
>         backend types 
>       * SMIME certificate revocation lists (CRLs) so certificates
>         expire, support for downloading the CRLs automatically on a
>         schedule
> 
> Evolution 2.6 (Spring 2006)
> Mail
>       * archiving of mail
> Contacts
>       * self/identity
>         http://lists.ximian.com/archives/public/evolution-
>         hackers/2004-February/002909.html 
>       * non canvas mini card view
> Calendar/Tasks
>       * rich text (HTML) for calendar/task descriptions
> Other
>       * desktop wide timezone setting 
>       * synchronization of evolution installs (settings, accounts,
>         data, etc) 
>       * expand/fix the shell api's to make them useful for remote
>         control/access to evolution. 
>       * removal of e-text (by gtktextview) 
>       * configuration of e-d-s without the evolution client
> 
> We should probably start collecting interesting EPlugin ideas as
> well: 
>       * create Appt from Msg 
>       * create Task from Msg 

Good idea.

>       * mail notification applet via a plugin that issues a DBUS
>         notification
> 
> Some other items to consider (not sure where/if they fit): 
>       * improving import/export (UI, error reporting, progress
>         reporting) 
>       * doing future migration in EDS itself 
>       * long term future of etable/etree 
>       * C# wrappers for ECalBackend and EBookBackend to make rapid
>         prototyping and testing easier 
>       * removing camel backend configuration from using a url to
>         specify all configuration, since that isn't dynamic enough.
>         Is kind of partially there with the persistent properties
>         thing. 
>       * expand/fix the shell api's to make them useful for remote
>         control/access to evolution.  Actually a whole overhaul of the
>         idl's wouldn't go astray, it isn't a huge task either.
>         They're nasty and kind of useless outside of evolution right
>         now (showURI is the only really usable method). 
>       * changing camel's store/folder apis to make them easier to
>         implement.  the ability to create a folder object without
>         opening the folder and the like, would simplify all the nasty
>         getfolderinfo and rename stuff. 
>       * using the plugin stuff to map things like backend
>         configurators to the frontend 'loosely'.  e.g. a custom camel
>         provider might include the camel code, but also a plugin which
>         the front-end will load *separately* to configure it, rather
>         than the messy camelprovider tables which don't provide much
>         flexibility.  The same could happen w/ eds rather than using
>         non-arbitrary property settings that the front-end needs to
>         have specific info about. 
>       * have product design revisit the SMIME UI 
>       * auto email harvesting from incoming messages (for
>         autocompletion) 
Cool!

>       * expose saved searches as subfolders of contact folders (or add
>         another root to the source tree: "Saved Searches" or "Contact
>         VFolders" or whatever).  It would be trivial to implement
>         these entirely in the UI (you just "(and <saved-query> <ui-
>         query>)" to do searches).  If possible, add in
>         ActiveDirectory's saved searches.
> 
> -JP
> -- 
> JP Rosevear <jpr novell com>
> Novell, Inc.