Hi there, I'm trying to dig up "the" EDS data structure which is currently used to hold calendar data. Searching the sources (among others, evolution-mapi), I found ECalComponent being used as a toplevel data structure for calendar data. Regarding this data structure, I found: "e-cal-component.[ch]: this contains ECalComponent, a GObject-based wrapper around libical's icalcomponent structure, although it does not offer all of its functionality (for instance, ECalComponent does not manage VCALENDAR objects)." -- http://www.go-evolution.org/EDS_Architecture#Calendar "We had some plans for using ECalComponent in all parts of Evolution/EDS hiding icalcomponent, am not sure whether we can still do it as ECal interface exposes icalcomponent in many places. It would be good to use ECalComponent as its object oriented and so would help us in avoiding copying icalcomponent structure at many places. ECalComponent would need more API’s for manipulating icalcomponent which is a reason why we use both of them." -- http://chenthill.wordpress.com/2008/08/ I'd like to know how you see ECalComponent's present (Evo2.30) status. Will it suffice for handling calendar stuff alone, or is icalcomponent still needed? We need this information for interface specification, and I'd like to avoid * crippling our interface by specifying a single data structure which does not cover all aspects needed for calendar data handling (is this the case for ECalComponent?) * using data structures which are in the process of being wrapped-up and hidden away in the near future (is this the case for icalcomponent?) aTdHvAaNnKcSe for any helpful information, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.