Hi there, On Wednesday 14 July 2010 Ross Burton wrote: > 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. Thanks for all input. This week, we should finish our initial planning phase and start implementing a few things. We'll have more time then to read code than it was the case before. I hope we'll have some spare time to organize all information into one document so it can serve as a reference. Most likely, it will be a copy&paste-thing gathering the answers we got here. I'll post a link once we have something ready. Best regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 Fax: +49-271-771091-19 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.