Re: [SyncEvolution] internal SyncSource API redesign
On Thu, 2009-08-06 at 21:35 +0100, Patrick Ohly wrote:
On Tue, 2009-08-04 at 16:10 +0100, Patrick Ohly wrote:
> The interfaces must be pure virtual to allow multiple inheritance.
> Default implementations of them provide the current functionality (for
> example, EvolutionSyncSource: iterate over fixed lists of changes,
> import/export items as blobs) and hook that up with the Synthesis DB
> Interface. An implementor can put all of his code in one class which is
> derived from the appropriate base classes.
I've implemented that concept and committed it to the "backend-api"
branch. Warning, the code is not stable. Be prepared for a somewhat
volatile branch and forced updates when pulling it.
I've pushed another revision to the branch. The Client::Source tests
pass now (*), so I'm optimistic that the refactoring didn't break
anything. Any further changes will be done as new commits on that
branch.
The patch is rather large, but it also removed a lot of cruft:
42 files changed, 2779 insertions(+), 3794 deletions(-)
One piece of functionality was removed and not added again yet: logging
of item changes as they occur. Previously, the syncevolution command
line would log "[INFO] addressbook: adding 'Doe, John'" or something
like it. This was implemented via some backend specific callback which
would peek into the item data to extract a short description.
A much better implementation in combination with the Synthesis engine
would be to read the right fields from the field list. I'll add an
utility class and the necessary hooks.
For items which existed locally and had to be removed on behalf of the
server, the backend had to read from the database. There's no way around
that, so I'll add that API again.
(*) When testing with Evolution 2.27.x, the current development version,
I noticed that testLinkedItemsRemoveNormal fails, but that happens also
with the "master" source and is caused by changes in the EDS calendar
backend: the parent's LAST-MODIFIED gets updated when removing a
detached recurrence. This is okay, the test should be relaxed.
--
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.