Re: [Evolution-hackers] Fwd: Re: [Evo and Kolab2 - a fresh attempt] Evo/EDS and The Big Picture

[Matthew Barnes <mbarnes redhat com>]

On Mon, 2010-06-21 at 18:28 +0200, Christian Hilberg wrote:
>   Does the "front-end process" refer to Evolution, i.e. is a Camel.Provider 
> running inside Evolution instead of EDS? I was hoping that all non-UI-related 
> stuff could be run inside EDS, so we would facilitate Evo only for account 
> setup and displaying purposes. Now, if Camel.Provider would run inside Evo, 
> this would complicate matters. Or maybe, we could get along without a 
> Camel.Provider for IMAP access?

I should have been clearer about this because it is confusing at first.

Everything email-related runs in the Evolution process.  The Camel
library is bundled in the Evolution-Data-Server source package, but has
nothing to do with the contact and calendar D-Bus services provided by
Evolution-Data-Server.

That said, I see no reason why you couldn't reuse Camel's IMAP provider
from your EBookBackend and ECalBackend if that works out to be the best
approach for your needs.  Certainly reinventing IMAP access yourself
would not be my first recommendation.


>   This means, at least part of the "calendar backend" will reside in 
> Evolution. We will have a helper lib which will convert Kolab2 XML format to 
> Evolution data structures. This lib was planned to live within the EDS backend 
> code. Now that I know that the Camel.Provider runs inside Evo, I'm not fully 
> sure whether putting the conversion lib inside our EDS plugin would be the 
> Right Thing(tm) to do.

Contact and calendar data residing on the Kolab2 server needs to be
accessible through the D-Bus services alone, even in the absence of
Evolution.  Remember, Evolution is just a front-end for those D-Bus
services -- not a required component.

Here's a vague idea -- not sure if this is feasible but it's probably
how I would approach the problem initially:

Each instance of a CamelProvider creates its own directory on the local
host for cached data.  Instead of setting up one CamelProvider instance
to be shared by all three processes, set up three instances and let each
process manage one of them: Evolution will manage the one for mail (like
any other CamelProvider), e-addressbook-factory will manage the one for
contact data, and e-calendar-factory will manage the one for calendar
data.  That way the three processes aren't stepping on each others' toes
trying to share a single local data cache.