Re: [Evolution-hackers] evolution-kolab: local cache for offline-work

Hi Chen,

thank you very much for taking time to clarify things! Much appreciated.

On Friday 09 July 2010 at 18:43:32 chen wrote:
> On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote:
> > * Does there exist any infrastructure in E-D-S which will help us
> > creating a local email cache via IMAP?
> Yes its available. CamelFolderSummary stores all the basic contents of
> an email which needs to be displayed in the MessageList view (label,
> subject, dates, from&to headers  etc.). CamelDataCache stores the
> contents of the email (entire mime message) into the cache. The imapx
> provider would use them to store the mail data into cache.

Okay, this helps. I think I saw these parts of Camel before, but I was not 
sure whether the facility provided would be sufficient for our needs. Seems we 
have what we need here.

> > * Orelse, is there a sensible way to re-use existing caching
> > functionality inside our backend which comes from Evolution, since Email
> > handling resides there, presently? Without weaving knots between Evo and
> > E-D-S which will be prone to failure and unclean, I mean?
> Current imapx provider implementation is in such a way that, once you
> access a message using camel_folder_get_message, the message would be
> completely downloaded into the cache and would be available for offline
> usage.
> camel_folder_refresh_info would fetch the summary contents and
> optionally fetch the message contents also if the folder is marked for
> offline usage (when the camel url property, 'sync_offline' is set).

Again, this is valuable information. If I read this correctly, the IMAPX 
implementation would handle all caching so we would be left with "only" the 
actual synchronization problem. BTW, is there a way to intercept Camel's 
synchronization with the IMAP server after reconnecting (i.e., after leaving 
offline mode)? This question is because the PIM emails hold semantics to which 
Camel will be agnostic (since it thinks it only handles emails), and it could 
be problematic to cope with PIM sync conflicts if Camel will just sync the 
emails right away without a possiblitiy for us to hook-in an awful lot of 
extra sync logic.

> And i guess you would be re-using the existing imapx backend from
> evolution ?

By all means! :-)

> Once you convert the xml data to Ical or VCard, you can make them
> available for offline usage based on ESource property, 'offline-sync'.

Well well, this all sounds promising.

> [...]
> > Once I'M really clear that we have to do these things fully on our own
> > and we cannot re-use existing infrastructure, I will instantly stop
> > harassing you with this issue and start working. :-) I just want to
> > avoid reinventing the wheel.
> Oh np :) You can shoot your queries anytime.. Btw to be more clear no
> one has tried using camel apis from calendar+address-book backends.

I think Matthew already mentioned this. But we will give it a try - not many 
options for us to choose from. :-) It might be a good idea to use separate 
instances of Camel providers for contacts and calendar data. We'll see.

Thanks for all the fish :-)


kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen

Attachment: signature.asc
Description: This is a digitally signed message part.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]