Hello Patrick, On Mar 18, 2010, at 16:22 , Patrick Ohly wrote:
>> Thanks for the feedback. After pushing I suddenly had the impression >> it could still be wrong for another case, I have to follow that >> thought first to make sure. So that's why I did not announce the patch >> out loud... > > It has passed all of my tests, so I'll go ahead and use this in the next > SyncEvolution snapshot. If you have more thoughts on what I should test, > please let me know. I will. It might be just a ghost, but I'll track it down :-) >> In both cases, it's the resumeAlertCode target field. If it is not >> zero, the datastore is resumable - i.e. a client will try to resume >> and a server will accept a resume. >> In binfile based setups, you can use >> the /profiles/xx/targets/<dbid>/resumeAlertCode settings key to access >> that value. > > In "both cases" - there are no targets in a server, so how would that > work there? I suppose it is part of the admin data, but that is internal > and and peeking inside it would bypass the official API. Yes, it would bypass the API, but unlike with binfiles, in the server case YOU are the provider of the storage for that admin data, and how the fields are stored is under YOUR control, and not a secret of the SyncML engine. So I'd guess it is ok to have a look at them (or even modify them - such as setting resumeAlertCode to zero to prevent a resume, or blank out the anchor to force a slow sync). Best Regards, 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
