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

[chen <pchenthill novell com>]

On Mon, 2010-06-21 at 14:05 -0400, Matthew Barnes wrote:
> 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.
Make sure to use the imapx provider as that's were, we are focusing our
efforts on.

> 
> 
> >   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.
Read through the conversation and the approach Matthew suggested would
be the best for this case. Question us if you have any doubts on the
virtual functions used in the backends.. 

- Chenthill.
> 
> _______________________________________________
> evolution-hackers mailing list
> evolution-hackers gnome org
> To change your list options or unsubscribe, visit ...
> http://mail.gnome.org/mailman/listinfo/evolution-hackers