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.

_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to