Are you writing a new backend similar to file/http/groupwise ? If so you can implement the virtual methods extending from ECalBackendSync class. You can prolly refer to any of the existing backends or evolution-exchange/calendar.
thanks, Chenthill. On Mon, 2006-07-31 at 04:22 -0400, Peter Colijn wrote: > 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 [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
