On Fri, 2010-07-09 at 19:20 +0200, Christian Hilberg wrote: > 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. You could connect to the signal 'changed' on the camel folder. This would give you information on new/deleted/changed messages once the folder is synchronized with the imap server.
http://live.gnome.org/Evolution/Camel.Folder - checkout CamelFolderChangeInfo . Btw the contents of the emails (mime message with Xml calendar/contacts data) would be cached in camel (usually under ~/.evolution/mail/imapx/<account>/folders/<folder>/ ) while mails are fetched (through camel_folder_get_message). You could delete those contents after converting them to ICal or VCard and storing the data in the respective backends, by using camel_data_cache apis from calendar/address-book backends to remove duplicate data. - Chenthill. > > > 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 :-) > > Christian > > > _______________________________________________ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers