Re: PROPOSAL: Evolution for GNOME 2.6

[Rob Adams <readams readams net>]

We'd be insane if we didn't put evolution into the desktop release. 
Would evolution be moving to gnome CVS/gnome bugzilla?

-Rob

On Sun, 2003-11-23 at 16:05, JP Rosevear wrote:
> The Evolution team would like to formally propose Evolution
> (http://www.gnome.org/projects/evolution) for inclusion in the GNOME 2.6
> Desktop release.
> 
> Currently this includes the following modules:
> evolution
> gtkhtml
> gal
> evolution-data-server
> 
> We are however endeavoring to remove gal as a dependency at this time.
> 
> We are moving to a 6 month release cycle to match the time based
> releases of GNOME.
> 
> It is our intention in the future propose evolution-data-server for
> inclusion in core platform.
> 
> There are two major parts of evolution now, the client (the UI) and the
> data server.  The client lives in the evolution module while the data
> server lives in evolution-data-server.  This has allowed us to make
> calendar and addressbook data access available to any GNOME application
> via a separate development package.  Some of the possible benefits of
> this can be seen at http://www.gnome.org/bounties.
> 
> The data server has some useful features:
> 
> * LDAP, DB3, flat file backends for the addressbook (VCard)
> 
> * Flat file, webcal/http, groupwise backends for the calendar
> (iCalendar)
> 
> * Pluggable architecture for backends 
> 
> * A per-user daemon that provides concurrent I/O and change     
> notifications, with C client libraries 
> 
> * Synchronous C client with multi-thread support and devel docs
> 
> * C# bindings
> 
> We have also worked on improving the client portion:
> 
> * Simplified UI and HIG-ification.  We have been moving away
> from the classic Outlook "folder tree + shortcut" model which has a
> number of usability issues; instead we are moving towards a model where
> calendar, address book and mail are separate entities and at some point
> it will be possible to launch them as separate applications.
> 
> * Simpler design.  The old architecture was very complicated and
> required a lot of knowledge to write a component, the new one is much
> more straightforward.
> 
> * Code refactoring: we have been cleaning up a lot of loose ends, trying
> to make the application more accessible to external developers.
> 
> * S/MIME 
> 
> We really want Evolution to become part of the platform in the long term
> to help drive more advanced features.  We're open to any feedback.
> 
> -JP