On Tue, 2010-07-13 at 15:36 +0200, Christian Hilberg wrote: > Hi again, > > no ideas? Anything? I will summarize some of the DataStructures here which you will be using in the backend,
ECalComponent - This holds the calendar event's data in Ical format. It wraps Icalcomponent, but has not completely wrapped the same. So both are used at places. ECalComponent is better to use as its a Gobject. ECalBackendSync - Abstract class from which you would need to subclass kolab backend. (http://live.gnome.org/Evolution/CalendarStore) ECalBackend - Use api's from this class to notify the clients on event changes (_remove, _added, _modified). ECalBackendStore - Abstract class for the calendar cache. ECalBackendFileStore - file is derived class of the above class and used for storing calendar contents. ECalBackendFactory - Abstract class for the factory which your backend needs to subclass. e-cal-utils.h - should have some utility functions. http://www.go-evolution.org/EDS_Architecture - I find that its not there in lgo, will need to be migrated. Having this as pointers and looking through existing backend implementation would give you a better idea. - Chenthill. > > Best regards, > > Christian > > _______________________________________________ > evolution-hackers mailing list > evolution-hackers@gnome.org > To change your list options or unsubscribe, visit ... > http://mail.gnome.org/mailman/listinfo/evolution-hackers _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
