Re: [Evolution-hackers] Evolution Future Roadmap

[Celso Pinto <cpinto yimports com>]

Hi,
although i'm not an Evolution hacker i'd like to comment on some of the 
future features:

In Evolution 2.2, events/tasks will have attachments. What kind of 
attachments are planned? Systems files? Or can one select an email and 
attach it to a task/event? (this feature got me on this list :) )

EPlugin: how will it work? It seems that there will be some 
mono-bindings but isn't it possible to provide some kind of scripting 
engine for this? I've heard about this kind of scripting on "Entourange" 
or something like that (MS PIM for MacOS). It'd be really really cool to 
provide this feature.

Cheers all,
Celso


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.
>
>
>     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 <mailto:jpr novell com>>
> Novell, Inc.
>