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 > _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
