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. Ok. > 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), Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.