Re: [Evolution-hackers] ECalBackend vs. ECalBackendSync

["Peter Colijn" <pcolijn gmail com>]

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