Hello Patrick,

On Jan 26, 2010, at 17:38 , Patrick Ohly wrote:

> As I might have mentioned before, in SyncEvolution we try to prevent
> unwanted slow syncs to give the user the chance to choose some other way
> of recovery (refresh sync, restore from backup):
> http://bugzilla.moblin.org/show_bug.cgi?id=2416
> 
> My current solution only partly works in a SyncML client: in the
> <alertscript>, the client checks the mode suggested by the server. The
> anchor check of the client happens after that, so if the client engine
> switches to a slow sync because the server's anchor is wrong, the slow
> sync is not prevented.
> 
> In a SyncML server, <alertscript> is called before any kind of anchor
> checking and thus not useful for this purpose at all.

What about <datastoreinitscript> or maybe <initscript>? These are called before 
user data is accessed the first time, which would be early enough to stop the 
whole thing if needed, but late enough to be sure the sync mode is known. BTW: 
I realized that a useful document was missing in the docs so far - see my 
latest commit 9dc1e5c1a3 (Doc: useful table showing the call flow of scripts 
within a server session) on the luz branch.

What's currently missing would be some DS-level functions to query the sync 
mode, but that'll be simple to add (probably in customimplds.cpp, within 
TCustomDSfuncs). To differentiate unwanted from client-requested slow sync, 
we'd probably need two of them, like ALERTEDMODE and ACTUALMODE. Some functions 
along this line already exist, I'd have to check to make sure we don't 
duplicate stuff.

What I don't really get is why the server would want to modify the client 
behaviour other than switching to slow sync (for two-way alert) or to refresh 
(for a one-way), which it already does.

> Here's a different idea. Instead of doing the checking via script, could
> the StartDataRead() in the datastore plugin do the checking? First
> problem: is this really called after the sync mode has been determined,
> in both client and server? Second problem: how can the plugin find out
> what the mode is?
> 
> I think StartDataRead() is called at the right time.

Yes, I would say so (without checking bit by bit). 

> The mode could be
> passed via a key, except that a) a server has no profiles and thus no
> per-datastore keys (right?)

Yes, the entire /profiles/ hierarchy does not exist in the server.

Lukas Zeller (l...@synthesis.ch)
- 
Synthesis AG, SyncML Solutions  & Sustainable Software Concepts
i...@synthesis.ch, http://www.synthesis.ch





_______________________________________________
os-libsynthesis mailing list
os-libsynthesis@synthesis.ch
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis

Reply via email to