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/
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
