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


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 
                -- 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 
* 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,


kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48    Fax: +49-271-771091-19
D-57072 Siegen

Attachment: signature.asc
Description: This is a digitally signed message part.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to