On Tue, 2012-08-21 at 11:31 +0200, Patrick Ohly wrote:
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?
As Lukas mentioned in another mail thread ("one-way sync + sync tokens
not updated"), the one-way sync modes are in fact meant to be part of a
two-way sync setup. They just temporarily disable sending changes in one
direction. With that intention in mind the current behavior (falling
back to two-way slow sync) makes sense again.
However, SyncEvolution doesn't support these modes properly, because its
change tracking only supports reporting of changes since the last sync.
That's a problem for another time, let's focus on one-way syncing for
PBAP.
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.
No, SETREFRESHONLY() just changes to traditional one-way sync.
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
"<readonly>". If
set, the engine will not only avoid sending changes to the client, it
will also remove those extra local items.
I've done it a bit differently: instead of adding a config option,
there's now only a macro call. The full code is in the "pbap" branch. I
also pushed the patches which use this feature into the "pbap"
SyncEvolution branch.
I'm attaching the libsynthesis patches for review. Lukas, does this make
sense? Can it get included upstream?
If yes, then I would rebase onto your latest code first. I held back
with that because I wanted to release 1.3 with minimal changes.
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).
Also done and attached.
It will be necessary to revise this handling a bit once more to cover
another PBAP use case: sometimes updating the cache is done with photos,
sometimes without (to reduce the amount of Bluetooth traffic). In the
later case the local PHOTO property must be preserved. Currently it gets
removed.
--
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.