On Wed, 2010-07-14 at 13:23 +0100, Ross Burton wrote: > On Wed, 2010-07-14 at 17:37 +0530, chen wrote: > > ECalBackendSync - Abstract class from which you would need to subclass > > kolab backend. (http://live.gnome.org/Evolution/CalendarStore) > > Though only subclass this if you can't handle the async nature of the > ECalBackend API yourself. Whether you subclass ECalBackend or > ECalBackenSync is a choice made by how the backend will be implemented. Is this used by any backends or will be used ? I was just having this question while reading through the go-evolution.org link. ECalBackendSYnc adds the notification to the clients for the sync calls made by the clients through libecal, which anyways cant be ignored isn it ? So usage of ECalBackend functions for sync calls such as, e_cal_backend_create_object, get_object, get_object_list etc. just adds extra work of notifying the clients using e_data_cal_notify*.
If the answer is, they are not used, better to mark them as deprecated and cleanup this area. ECalBackend can then just be used for Async apis like, e_cal_backend_notify_object_(added, modified, removed) and future free/busy async apis etc. - Chenthill. > > Ross _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
