Re: [Evolution-hackers] [evolution-kolab] Datastructures for calendar data

[chen <pchenthill novell com>]

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