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

[chen <pchenthill novell com>]

On Fri, 2010-07-09 at 18:25 +0200, Christian Hilberg wrote:
> On Friday 09 July 2010 at 18:01:53 chen wrote:
> > [...]
> > Let me try to summarize some pointers for calendar and you could do the
> > same for address-book as well,
> > + Create New ECalBackend for Kolab
> > + Use the camel apis to fetch the calendar folder
> > + Using the CamelFolder, get its contents. You would mime data and you
> > can use the Camel libraries again to parse these contents.
> > + Convert the Xml calendar data into Ics format and store it into the
> > backend
> 
> Yeah, this much is clear. There will be a fully-fledged two-way lossless 
> conversion between EDS data types and Kolab2 data types, and the conversion 
> will most probably be done on-the-fly (if we run into performance issues here, 
> we might change plans... :).
> 
> > So this helps for displaying the contents. Now with creating
> > meetings/appointments. iirc you would need to send them via smtp ?
> > + use the camel_transport apis (look through e_cal_backend_save/send
> > api's)
> 
> Also no worries so far.
> 
> Let me be a little more specific (I should have been right away, but my mails 
> tend to become lengthy...):
> 
> * We need to create a local cache for emails which is handled by the plugin 
> backend(s).
> 
> * 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.

> 
> * 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).

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

Once you convert the xml data to Ical or VCard, you can make them
available for offline usage based on ESource property, 'offline-sync'.
> 
> 
> > There are many backend implementations already available file, exchange,
> > groupwise etc. and you can refer them.. I would recommend looking
> > through groupwise/exchange and shoot your questions if any..
> 
> I'm in the process of having a closer look at them...
> 
> > Since no one has yet tried using camel apis, we do not know if there are
> > any issues while you might face. But we should be able to help you while
> > you progress..
> 
> Okay, thanks.
> 
> 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.

Thanks, Chenthill.
> 
> Best regards,
> 
> 	Christian
>