Hi Chenthill, On 7/31/06, chenthill <[EMAIL PROTECTED]> wrote: > You would need to implement both. The ECalBackendSync class has a > sync lock, which is used if the backend can handle only one operation at > a time. It provides the results immediately to the caller. > ECalBackend class provides notifications to the client from EDS. > Please go through http://www.go-evolution.org/EDS_Architecture for more > details.
On that page, it says "To write a calendar/tasks backend, a subclass of ECalBackend (for asynchronous) _OR_ ECalBackendSync (for synchronous) needs to be written." (emphasis mine) If both need to be implemented, perhaps that article should be updated? I can see how I could implement EBackendSync, then implement EBackend on top of that by having a worker thread that calls the EBackendSync calls. Is that what you're referring to? > It depends on how client is designed. Well, my intended client is Evolution :P With Evolution as the client, if I implement ECalBackendSync, will the UI block? Harish mentioned that I could avoid having the UI block if I had a separate thread for repainting. But if I'm just adding a new calendar backend, and I want to use it from Evolution, am I writing any code to do redrawing, etc? I certainly hope not! Thanks! Peter _______________________________________________ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
