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

[chen <pchenthill novell com>]

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