For the PBAP caching mechanism in SyncEvolution I'd like to use the
Synthesis engine. I think that makes sense because the engine does a few
things which would have to be done manually otherwise (translate between
formats, finding pairs). The improvements below would also make sense in
other use cases.
At the moment the engine (or rather, SyncML) lacks a few things which I
need to change. I'm focusing on one-way-from-client syncing because the
server has a bit more control over what it does and because it matches
the SyncEvolution use case.
In SyncML, incremental one-way syncs fall back to a two-way slow sync
after a failure. If the server has an item which the client no longer
has, then the item will be recreated on the client, despite the
intention to only transfer data in one direction. Right?
This is undesirable in general (IMHO), and an absolute no-no for PBAP as
the client, because it cannot write the changes.
As a first step I would disable sending changes to the client if the
client asked for a one-way-from-client sync. The server's datastore can
already be marked read-only (<readonly> config option, SETREADONLY());
something similar for the peer's datastore would make sense. Then I
could leave the default behavior as it is and use a script function to
trigger the desired behavior.
Actually, there is SETREFRESHONLY(). According to the docs, it is meant
to be used for turning a two-way sync requested by the client into a
refresh-from-remote. I need to check whether I can use that or still
need to add/modify something.
Suppose a slow sync was done in that modified refresh-only mode. Any
item that the server has which are not on the client need to be removed
if the server's storage is meant to mirror the client.
At the moment, the engine cannot know whether it is meant to mirror the
data and thus it will leave the extra items on the server unchanged. I
intend to add a "<mirror>" config option similar to
set, the engine will not only avoid sending changes to the client, it
will also remove those extra local items.
Finally, during a slow sync where a match was found, extra properties in
the server's copy of an item must be removed to avoid keeping stale
data. This can already be done by configuring the merging of items
accordingly (instead of preserving as much data as possible, ensure that
the client's item is always considered the "winning" one and that its
version completely overwrites the server's).
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.