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 <[EMAIL PROTECTED]> > Novell, Inc. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
