[Evolution-hackers] Evolution Future Roadmap
JP Rosevear
jpr@novell.com
Wed, 21 Jul 2004 12:43:15 -0400
--=-xgGLvSuKXn32q2f0syzo
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
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.
--=-xgGLvSuKXn32q2f0syzo
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.1.17">
</HEAD>
<BODY>
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.<BR>
<BR>
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.<BR>
<BR>
Bring on the feedback.<BR>
<BR>
<H2>
<FONT COLOR="#ff0000">Evolution 2.2 (Spring 2005)</FONT>
</H2>
<H3>
Mail
</H3>
<UL>
<LI>IMAP rewrite to improve async server notification handling (IMAP4 camel provider)
<LI>detaching camel from evolution
<LI>read/delivery receipts of messages via RFC
</UL>
<H3>
Contacts
</H3>
<UL>
<LI>supported fields handling (supported/not supported, required, ranges allowed) so the editor can disable fields appropriately
</UL>
<H3>
Calendar/Tasks
</H3>
<UL>
<LI>our own libical implementation based on the vcard parser
<LI>detached instance support in the GUI and file backend
<LI>supported fields handling (supported/not supported, required, ranges allowed) so the editors can disable fields appropriately
<LI>use range of time (ie 10am for 1 hour) for time selection in
<LI>attachments to events/tasks
</UL>
<H3>
EPlugin
</H3>
<UL>
<LI>hook into any popup menu
<LI>hook into main menu's, based on current view and view context.
<LI>hook into configuration pages
<LI>hook into in-line display of mail content, at the very least for imip and the like.
<LI>mono wrappers to write plugins
</UL>
<H3>
Groupwise
</H3>
<UL>
<LI>proxy user access
<LI>shared folders
<LI>permission management
<LI>delivery and read receipt status tracking
<LI>retract and recall messages
</UL>
<H3>
Exchange
</H3>
<UL>
<LI>integrate ximian-connector-setup functionality into the Evo Acct Assistant for adding Exchange account
<LI>remove need for separate exchange component for public folder handling
<LI>delivery and read receipt status tracking
<LI>open other user's entire mailbox
<LI>display pre-emptive password expiration warnings
<LI>display quota messages sent by Exchange Server Display folder sizes
<LI>display Favorites folders
<LI>add/remove Favorites folders
</UL>
<H3>
Other
</H3>
<UL>
<LI>RTL support in GtkHTML
<LI>merge needed gal pieces into evolution
<LI>inclusion of exchange support directly in eds
<LI>loadable backend modules in eds
<LI>gnome-key-ring instead of e-password (e-password could be a wrapper)
</UL>
<H2>
<BR>
<FONT COLOR="#ff0000">Evolution 2.4 (Autumn 2005)</FONT>
</H2>
<H3>
Mail
</H3>
<UL>
<LI>camel plugins
<LI>server side rules
</UL>
<H3>
Contacts
</H3>
<UL>
<LI>default to using flat file backend
<LI>online/offline support for LDAP
</UL>
<H3>
Calendar/Tasks
</H3>
<UL>
<LI>decline/counter and counter support
<LI>comments when declining IMIP requests
<LI>online/offline support using cache for webcal
</UL>
<H3>
EPlugin
</H3>
<UL>
<LI>filter types, if camel filters can also be customisable (needed for server-side rules)
<LI>pluggable junk stuff, although some of that might need camel plugins instead.
<LI>event stuff, like 'message shown', 'folder opened',
<LI>backward hooks so you could do things like run a server which interacts with internal data
</UL>
<H3>
Groupwise
</H3>
<UL>
<LI>online/offline support
<LI>server side rules
<LI>delay delivery of mail until specified time
<LI>request reply of mail within a specified time frame
</UL>
<H3>
<FONT COLOR="#000000">Exchange</FONT>
</H3>
<UL>
<LI>online/offline support
<LI>server side rules
<LI>task delegation
</UL>
<H3>
Other
</H3>
<UL>
<LI>unified account support to share connection information among backend types
<LI>SMIME certificate revocation lists (CRLs) so certificates expire, support for downloading the CRLs automatically on a schedule
</UL>
<H2>
<BR>
<FONT COLOR="#ff0000">Evolution 2.6 (Spring 2006)</FONT><BR>
Mail
</H2>
<UL>
<LI>archiving of mail
</UL>
<H3>
Contacts
</H3>
<UL>
<LI>self/identity <A HREF="http://lists.ximian.com/archives/public/evolution-hackers/2004-February/002909.html">http://lists.ximian.com/archives/public/evolution-hackers/2004-February/002909.html</A>
<LI>non canvas mini card view
</UL>
<H3>
Calendar/Tasks
</H3>
<UL>
<LI>rich text (HTML) for calendar/task descriptions
</UL>
<H3>
Other
</H3>
<UL>
<LI>desktop wide timezone setting
<LI>synchronization of evolution installs (settings, accounts, data, etc)
<LI>expand/fix the shell api's to make them useful for remote control/access to evolution.
<LI>removal of e-text (by gtktextview)
<LI>configuration of e-d-s without the evolution client
</UL>
<PRE>
</PRE>
We should probably start collecting interesting EPlugin ideas as well:
<UL>
<LI>create Appt from Msg
<LI>create Task from Msg
<LI>mail notification applet via a plugin that issues a DBUS notification
</UL>
<BR>
Some other items to consider (not sure where/if they fit):
<UL>
<LI>improving import/export (UI, error reporting, progress reporting)
<LI>doing future migration in EDS itself
<LI>long term future of etable/etree
<LI>C# wrappers for ECalBackend and EBookBackend to make rapid prototyping and testing easier
<LI>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.
<LI>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).
<LI>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.
<LI>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.
<LI>have product design revisit the SMIME UI
<LI>auto email harvesting from incoming messages (for autocompletion)
<LI>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.
</UL>
<PRE>
-JP
--
JP Rosevear <<A HREF="mailto:jpr@novell.com">jpr@novell.com</A>>
Novell, Inc.
</PRE>
</BODY>
</HTML>
--=-xgGLvSuKXn32q2f0syzo--