On Tuesday 12 February 2008, Michael Bell wrote:
> >>> Output from 1) and 2) respectively below. Note how entries are
> >>> transferred FROM the file-sync only in case 2). The problem in 1)
> >>> seems to be that msynctool doesn't request a slow-sync from ALL devices
> >>> when one of them does a full sync.
> >>
> >> Perhaps we need advice from a more senior project member. Is this an
> >> OpenSync or a msyntool bug? The SyncML plugin signals slow sync via
> >> the sink.
> >
> > Could it be a timing problem? I.e., that syncml signals a slow-sync
> > when the file-sync plugin has already started doing a two-way-sync?
>
> The problem is that the SyncML plugin detects the necessary slowsync
> during the get_changeinfo call or better during the processing of the
> get_changeinfo request. There is no function where we determine the type
> of synchronization.
>
> @Daniel: is this correct?
Slow Syncing gets triggered like this:
#1 Group was locked -> All Object Engines get triggered for a slow-sync.
#2 Plugin triggers slow-sync: anchor mismatch (which should be the case if it
got synced in meanwhile with another environment)
In this case 2nd should appear. The Object Engine(s) should get set to perform
a Slow Sync. Then it's up to the plugin in the get_changes sink function to
check if a slowsync got requested by the Object Engine or not.
If not all plugins perform a plugin there are two possibilities what went
wrong:
#1 Buggy Plugin which doesn't check for SlowSync carefully in the
get_changes() function (in this case the file-sync plugin... but it checks
correctly the sink for slowsync in the get_changes() function)
#2 OpenSync doesn't flag the correct Object Engine to perform a slow-sync. So
the Sink Engine isn't flagged and the plugin will not perform a slow-sync.
(VEEEERY LIKELY since we did some changes with the sinks!!!!!!!!!!!!!!!!
Michael already mentioned this in another mail.)
|
