Re: [os-libsynthesis] [PATCH] SAN 1.1 generation support: Moved utility code from engine to sdk
Hello Congwu, I just merged your SAN 1.1/1.0 changes from the moblin/san11 branch into our master (2dd107df40c551a5517beb4a751c02e9277890a6). Also merged are some other changes from moblin/master. I'm still in the process merging these with our internal codebase and push the (few) updates from there to libsynthesis. But the current master has all the moves needed to authorize the LGPL-BSD move for the files needed outside the engine for SAN 1.1. 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
Re: [os-libsynthesis] suspend failure
On Tue, 2010-03-16 at 14:40 +, Lukas Zeller wrote: Most probably, there should be an extra check for that too late suspend. Your patch in the luz branch works, thanks a lot. Now I just have the inverse problem: the tests pass even if the suspend requests were ignored entirely. Manually checking the next log shows that we did resume and we get the progress event which tells us that the session was resumed. But it would be nice if this could be checked already before running that next sync. Is there a possibility to retrieve the datastore is suspended information from a binfile-based client? Is it possible in a server? -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] suspend failure
Hello Patrick, On Mar 18, 2010, at 14:00 , Patrick Ohly wrote: On Tue, 2010-03-16 at 14:40 +, Lukas Zeller wrote: Most probably, there should be an extra check for that too late suspend. Your patch in the luz branch works, thanks a lot. 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... Now I just have the inverse problem: the tests pass even if the suspend requests were ignored entirely. Manually checking the next log shows that we did resume and we get the progress event which tells us that the session was resumed. But it would be nice if this could be checked already before running that next sync. Is there a possibility to retrieve the datastore is suspended information from a binfile-based client? Is it possible in a server? 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. 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
Re: [os-libsynthesis] suspend failure
On Thu, 2010-03-18 at 14:05 +, Lukas Zeller wrote: Hello Patrick, On Mar 18, 2010, at 14:00 , Patrick Ohly wrote: On Tue, 2010-03-16 at 14:40 +, Lukas Zeller wrote: Most probably, there should be an extra check for that too late suspend. Your patch in the luz branch works, thanks a lot. 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. But it would be nice if this could be checked already before running that next sync. Is there a possibility to retrieve the datastore is suspended information from a binfile-based client? Is it possible in a server? 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. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] suspend failure
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
Re: [os-libsynthesis] suspend failure
On Thu, 2010-03-18 at 15:36 +, Lukas Zeller wrote: [server admin data] 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). So the format is part of the API? I guess it has to be even though it is not documented (or is it?), because changes to it would break server software upgrades. -- 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. ___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] suspend failure
On Mar 18, 2010, at 16:55 , Patrick Ohly wrote: On Thu, 2010-03-18 at 15:36 +, Lukas Zeller wrote: [server admin data] So the format is part of the API? I guess it has to be even though it is not documented (or is it?), because changes to it would break server software upgrades. Probably the plugin API variant is not explicitly documented, probably because it is possible (and fully functional) to look at the admin data text format as an opaque string, and just save/retrieve it as-is, without bothering what's in the fields. However, on the SQL/ODBC level, it was always documented in the config reference in 12.20.2 synctargetgetsql, synctargetnewsql, synctargetupdatesql, synctargetdeletesql: Sync target management. That's only semi-useful for plugins, as in the SQL case there are no field names. But it describes the semantics. 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
