Hi Milan,
thanks for your explanations, though they undermine what little idea about
Evolution design I thought I had... ;-)
On Friday 23 July 2010 Milan Crha wrote:
On Fri, 2010-07-23 at 10:43 +0200, Christian Hilberg wrote:
We would need the possibility to define extra D-Bus communication
between Evo and E-D-S for that, right?
[...]
What I thought you'll do the easiest way was to define your own camel,
subclass of imap/imapx, and add some property of source-type to it,
which will lead folder showing on all of them. This camel part will be
compiled first, because you will need it in book/cal backends. Note
you'll have three simultaneous connections to your server, from three
different processes.
I must admit that I am not yet familiar with the communications structure
between Evo and E-D-S processes. If we let one Camel Provider live in
Evolution, then we need to access it's data from the address book and calendar
backend (or the data has to be pushed to the backends), which will be
complicated at best or may not work at all (corrections always welcome!).
If we have three instances of our IMAPX subclassed Camel provider, then each
instance needs to know which process it lives in (Evo for Email-only, calendar
backend process, address book backend process). If each Camel Provider
instance knows where it lives, it can then deduce which folder types it may
access and present only those to the surrounding process. That way, we would
have concurrent accesses to the IMAP server but at least we'd not be accessing
the same data concurrently (other than the folder lists, which should be
accessed read-only in most cases anyway). This might work, but I do not feel
fully well with this solution... especially when it comes to nested IMAP
folders which may be of different types (I'll have to check again whether
Kolab allows such).
I do not think moving mailer part to eds would help you much, the time
where there was only one evolution-data-server-X.YZ process is gone :)
Evolution exchange had been also running as a separate process,
independently from evo and factories, some time back, which is very
similar to your proxy, but it wasn't working well, so it was also
rewritten in time of 2.29 (I think). Anyway, it is possible this way
too; you'll get less connections to your Kolab server, if nothing else.
Okay, I'll have to re-think this design then. I may have funny ideas at times,
and some of them even work, but one would not have rewritten a plugin if the
independently running stuff would have been a good road to take. :)
Happy hacking,
Christian
--
kernel concepts GbRTel: +49-271-771091-14
Sieghuetter Hauptweg 48Fax: +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
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
