On Monday 21 June 2010 at 20:05:25 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.

If a Camel.Provider will work inside an E<Book|Cal>Backend, then that would be 
the route for us to take, since access to everything in Kolab2 is done via 
IMAP (other than reading a global address book, which can also be done via 
LDAP). New Book/Cal entries (updating is a matter of delete-create) are sent 
via SMTP. That means we will certainly try to use Camel inside the backends. 
Hope it works. :)

> [...] 
> 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.

Sounds good to me. For Email handling, I think we could as well use the 
existing Evolution infrastructure. To me, there does not seem to be a need for 
a separate Camel.Provider in our EPlugin (we just would need to configure a 
new IMAP account for that - and that same IMAP account (data) would be re-used 
to connect the E<Book|Cal>Backends to the Kolab server). If I'm mistaken on 
that, I'll happily accept corrections.
By the way, are there any known pitfalls using multiple instances of Camel 
simultaneously? I think I've read something about Camel not being 
multithreading-safe (can't seem to find the link just now), but our backends 
will likely be async ones. Will multiple Camel.Provider-instances interfere 
with one another at any point?

Greetings (and thanks for all the fish so far),


kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen

Attachment: signature.asc
Description: This is a digitally signed message part.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to