On Wed, 2010-07-14 at 20:14 +0530, chen wrote:
> > 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.
But if your backend can make async calls (say you implement it using
GIO) then you can drop the BackendSync layer and notify yourself. One
of my plans was to move the "each operation in a thread" logic into
E*BackendSync because asynchronous backends obviously don't need to be
in a thread.
Ross
--
Ross Burton mail: ross burtonini com
jabber: ross burtonini com
www: http://burtonini.com
Attachment:
signature.asc
Description: This is a digitally signed message part