Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync

[chenthill <pchenthill novell com>]

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 <pchenthill novell com> 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