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/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
