[g-a-devel]Re: PROPOSAL: Evolution for GNOME 2.6

[Bill Haneman <Bill Haneman Sun COM>]

I really don't think we should integrate something as big as Evolution
without integrating the accessibility work.

I understand that there is substantial accessibility work going on for
Evolution (client) at this time, but for scheduling reasons it's not
happenning on the HEAD branch AFAIK.  I'd like to get this merged into
HEAD before we bundle Evo with an official GNOME community release.

Since the accessibility work is already going on, and is apparently well
advanced, I think that would be a reasonable integration requirement. 
Would that be acceptable to the Evo team?

best regards,

- Bill
> > 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