Re: [Evolution-hackers] Evolution Future Roadmap

[Sam Gallant <sgallant gmail com>]

I'm not sure if this is the best place to submit this (don't you love
it when people start this way), but I would like to make a suggestions
for a feature. Specifically I would love to see the ability to use a
triple vertical pane view like Outlook 2003 and Thunderbird. As
widescreen displays are becoming more popular the triple verical panes
really increases the utilization of the available space.



On Wed, 21 Jul 2004 12:43:15 -0400, JP Rosevear <jpr novell com> 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.
> 
> 
> 
> 
> 
> 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
> 
> 
> 
> 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
> 
> 
> 
> 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)
> 
> 
> 
> 
> 
> 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 
>     
> 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)
>     
> 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.
> 
> 
> 
>