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