1:10 a.m.
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.
6:35 a.m.
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.
The code currently is complete enough to run sync sessions with the
command line. The GUI and syncevo-dbus-server also compile. What is
missing is the adaption of ClientTest.cpp to the updated API. Therefore
it doesn't compile yet, which prevented more intensive tests today.
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.
The equivalent of the former EvolutionSyncSource is now SyncSource.
EvolutionSyncSource made a comeback as base class for all EDS sync
sources.
TrackingSyncSource documents the whole API, just as it did before, even
for those methods which are inherited from base classes. The goal is
that someone can copy/paste that class, fill out the pure virtual
functions and be done with his work (okay, after registering his
backend).
Bob, for your purposes (reusing change tracking via revision string, but
accessing field lists directly), you would compose a class roughly like
this (untested):
#include <boost/bind.hpp>
class FieldListSyncSource : public SyncSource,
public SyncSourceSession,
public SyncSourceRevisions,
public SyncSourceDelete {
public:
FieldListSyncSource(const SyncSourceParams ¶ms) :
SyncSource(params)
{
SyncSourceSession::init(m_operations);
SyncSourceRevisions::init(NULL, NULL, m_operations); // APIs for backup/restore
not available
SyncSourceDelete::init(m_operations);
m_operations.m_readItemAsKey =
boost::bind(&FieldListSyncSource::readItemAsKey,
this, _1, _2);
m_operations.m_insertItemAsKey =
boost::bind(&FieldListSyncSource::insertItemAsKey,
this, _1, _2);
m_operations.m_updateItemAsKey =
boost::bind(&FieldListSyncSource::updateItemAsKey,
this, _1, _2, _3);
}
sysync::TSyError readItemAsKey(sysync::cItemID aID, sysync::KeyH aItemKey);
sysync::TSyError insertItemAsKey(sysync::KeyH aItemKey, sysync::ItemID newID);
sysync::TSyError updateItemAsKey(sysync::KeyH aItemKey, sysync::cItemID aID,
sysync::ItemID updID);
};
See sysync_dbapi.h for information about the *AsKey() Synthesis calls. I
can imagine that some C++ glue code like in SyncEvolution's
SynthesisEngine.h will make it easier to work with that API.
I won't have much time to work on this tomorrow, I have to catch up with
my other work first. At least I should get client-test compiled and
running again.
The next steps would be to get the SQLiteContactSource working with the
new API and direct field list access. It was meant as a coding example
that works on all platforms, but due to bit rot and neglect during the
0.9 release cycle it currently doesn't compile (same problem as in Mac
OS X, dependency on removed VOCL vCard parse/encoder).
Yongsheng, perhaps you want to have a look at that? It would be a good
check for the new API if someone else could go through it, check whether
the comments all make sense/are up-to-date, and then uses it in a new
way.
--
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.
12:04 a.m.
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.
2:30 a.m.
On Mon, 2009-08-10 at 15:04 +0100, Patrick Ohly wrote:
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.
This is available now via the new SyncSourceLogging. Evolution contact
source reimplements the logging with it in a nicer way and
calendar/task/memo source print an item description using the new
infrastructure for the first time.
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.
See SDKInterface and get/setValue(). This currently works for string
fields, other types coukld be added in a similar way.
There also were quite a few bug fixes. Spare me the trouble (and
embarrassment) of listing them here; see the branch history for details
instead...
--
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.
6:08 p.m.
On Thu, 2009-08-13 at 17:30 +0100, Patrick Ohly wrote:
> 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.
See SDKInterface and get/setValue(). This currently works for string
fields, other types coukld be added in a similar way.
There also were quite a few bug fixes. Spare me the trouble (and
embarrassment) of listing them here; see the branch history for details
instead...
... except that I now have rebased the branch and merged all bug fix
commits into the initial API change commit, in preparation for getting
this merged into the "master" branch.
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).
--
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.
6:38 p.m.
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
6:29 p.m.
>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?
11:41 p.m.
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.
4771
days inactive
4793
days old
syncevolution@synevolution.org
7 comments
2 participants
participants (2)
-
Chen, Congwu -
Patrick Ohly