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 :-)
Christian
--
kernel concepts GbR Tel: +49-271-771091-14
Sieghuetter Hauptweg 48 Fax: +49-271-771091-19
D-57072 Siegen
http://www.kernelconcepts.de/
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
