Hi Patrick,
On Oct 1, 2009, at 15:58 , Patrick Ohly wrote:
> The client controls the sync modes. The server just executes what
the
> client wants.
There may be cases where our datastore cannot execute an incremental
sync. What is the best way to force a slow sync? Erasing the admin
data
(possible now that it is under our control)?
Yes, forcing a slow sync is possible, but not change the sync type
(fromserver/toserver/twoway).
First of all - I hope this is more theory than actually happening,
slow syncs are EVIL and should be avoided whenever possible :-)
I would not erase the entire admin data - it is sufficient to clear
the anchors, then the server engine will detect out-of-sync and force
a slow sync. If you clear the entire admin data, you'll get a slow
sync as well, but additionally it will have the "first sync" attribute
as well, which can lead to different slow sync matching policies
(trying to intergrate a formerly independent data set vs re-establish
mapping with a data set that already was in sync once before).
You could also set session variables (via the session key) from your
DB plugin and have certain scripts (like <alertscript>) check the
session variable and call FORCESLOWSYNC()). This would be the way to
do more fancy stuff like settings slowsync strategies, making a
session read-only, adding sync set filters etc. which can't be done in
admin data. See config reference for <alertscript> and
<datastoreinitscript>. You'll see that you even could try to set the
sync mode to something arbitrary using SETALERTCODE(), but this does
not mean it would actually work with clients if it's more than forcing
slow sync...
> Note that the server does not have progress events at this time
at
> all. Could be added, but requires some work, and would require to re-
> architect the progress events to some degree as these are all global
> (engine level) now, and would need to be made separate per session.
That would be very worthwhile for our use case ("personal SyncML
server"). When initiating a sync with a phone connected via Bluetooth,
we would do that using our sync GUI on the desktop. It would be useful
if the GUI could display progress also for such a sync, ideally the
same
way as when it runs as client.
That's certainly the plan. Once we have the unilib (my work title for
the unified client/server engine library), this will become easier to
do, as many differences between the two variants will be ironed out by
then already.
Best Regards,
Lukas Zeller (luz(a)synthesis.ch)
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
info(a)synthesis.ch,
http://www.synthesis.ch