Re: [SyncEvolution] internal SyncSource API redesign
On Wed, 2009-08-26 at 09:29 +0100, Chen, Congwu wrote:
>>Congwu, you are currently looking into the backend API as
part of the
>>SDK tutorial work. Can you review the "backend-api" branch? I'd
like to
>>get it merged tomorrow, after one full nightly test run with your
>>"message resend" patches. The goal is a 0.9.1 release with these
changes
>>middle of September (but that also depends on the D-Bus API discussion,
>>bug reports and demand).
>Yes, I will look at it
Looks good.
One small question:
SyncSourceSerialize: SyncSourceBase, SyncSourceRaw and
SyncSourceRaw: SyncSourceBase
Why do we need extend SyncSourceBase again in SyncSourceSerialize?
It's redundant, but it also doesn't hurt ("virtual public" ensures that
the class is only inherited once). One advantage is that
SyncSourceSerialize doesn't have to make the assumption that
SyncSourceRaw is derived from SyncSourceBase.
SyncSourceRevisions does the same thing.
Okay, so I went ahead, rebased the branch against the latest master and
merged it. Let's see how this breaks, eh, passes the nightly testing.
In related news, I've tentatively scheduled "#5049 - sqlite: field list
sync source" for SyncEvolution 0.9.1. It would be really nice to get
this example backend up to the latest source code revision again
together with the backend API change.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.