[SyncEvolution] internal SyncSource API redesign
Hello!
Bob's questions made it clear that some of the internal API changes
should be done rather sooner than later. There are several other
enhancement ideas which depend on similar changes:
#5047 ODBC sync source
#5049 field list sync source (the feature needed by Bob)
#5046 raw file sync source
#3472 SyncEvolution code cleanup (EvolutionSyncClient and
EvolutionSyncSource class names, namespaces)
Let me summarize my current thinking. In order to do something useful in
SyncEvolution, a backend
* must implement the part which integrates it into the framework
(meta information like name, Synthesis XML config fragments) =>
SyncEvolutionBackend, a subset of the current
EvolutionSyncSource
* must implement the Synthesis DB Interface, a varying (depending
on the backends capabilities) number of C-style function
callbacks => provide a mechanism how SyncEvolution backends can
bind these callbacks to methods in their own object, but without
prescribing a specific interface as EvolutionSyncSource does
right now
* if automatic testing is desired, it must implement a standard
interface for iterating over changes and another interface to
import/export data (in contrast to the current solution, were
iterating over items includes item data exchange - this was
inherited from the Funambol C++ client library and should be
changed also for other reasons)
* if backup/restore is desired, another interface for that must be
implemented
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.
The current EvolutionSyncSource and TrackingSyncSource would do that to
preserve the current, rather simple to implement API, and to avoid
rewriting existing backends. I would rename EvolutionSyncSource though
and move the remaining Evolution specific code into a common class in
src/backend/evolution.
--
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.