4 Aug 17:10
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)
(Continue reading)
RSS Feed