Re: [os-libsynthesis] DB SaveDeviceInfo
On Fri, 2009-11-13 at 11:36 +, Beat Forster wrote: > > Hi Patrick, > > > > On Nov 12, 2009, at 19:20 , Patrick Ohly wrote: > > > If the device info is meant to be used by the DB, then its format > > would > > > have to be documented somewhere. Is it documented and I just > > missed it? > > It seems that it is not documented :-( It should be, of course, as > > part of the SDK manual. > IT IS DOCUMENTED in the current SDK manual, page 51. > The correct name is Session_SaveDeviceInfo. I pretty much stopped using the SDK manual because in several cases it just points towards sync_apidb.h as the reference documentation for the API calls - if I remember correctly. As I said, I haven't looked it for a while ;-} To make the information easier to find, I'd suggest to a least reference the SDK manual in sync_apidb.h or put the format description there completely. Then the SDK manual can include that information as part of the Doxygen-generated parts - you have those, don't you? -- 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] server login without credential check
Hi Patrick, On Nov 10, 2009, at 18:43 , Patrick Ohly wrote: > There are quite a bit of changes in your "luz" branch and some unmerged > ones in our "master". Should we merge the changes back and forth so that > we are in sync again? Probably yes. Now that unilib has become the main line, I'm back with the old scheme - my current work on "luz" (with a little bit of risk that something in there might not yet work in different contexts than mine) and "master" being pulled up from time to time as a more official and more conservative "release" branch. >> Now for your change - I disagree because it makes it impossible for a >> DB plugin to handle invalid, anonymous AND regular logins. > > Okay. I reverted the change. > >> The purpose >> of is just an extra security barrier to set a minimal >> login requirement. Setting it to "none" should not mean that >> necessarily *all* sync attempts need no credentials, but allows that >> *some* might not need them. In any case, the DB layer (or the >> scripts) decides about allowing a session or not on a case- >> by-case basis. > > I didn't see a possibility to do that in the DB layer, at least not with > the old code. Indeed, the really anonymous case (no credentials at all) was impossible to handle in the plugin. >> For a server that does not need any checking, just put a "return TRUE" >> into . > > That works. I added it to SyncEvolution "master". :-) 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] failure to add item in DB, but sync successful?!
Hello Patrick, On Nov 10, 2009, at 19:31 , Patrick Ohly wrote: > On Tue, 2009-11-03 at 18:23 +, Lukas Zeller wrote: >> On Nov 3, 2009, at 14:09 , Patrick Ohly wrote: >>> Second observation: the failure is not recorded and thus doesn't >>> show up >>> in the sync statistics or the overall sync result. Is this expected? >> >> Not really. I'd expect it to get recorded as "rejected". I'll have a >> look. > > Did you find out something about this? Hm - looking at your log snippet... > Just for the record, the log shows the problem like this: > >–[2009-11-03 14:05:14.381] End of 'ScriptExecute' > [->top] [->enclosing] >[2009-11-03 14:05:14.382] # SyncEvolution (LNK): > InsertItemAsKey: ical20 025B6F50 >[2009-11-03 14:05:14.382] adding "fake timezone with > daylight starting in May" >[2009-11-03 14:05:14.383] ical20: extracting event >[2009-11-03 14:05:14.383] cannot create record in > database (sta=510) >[2009-11-03 14:05:14.383] Database Error --> SyncML > status 510, dberr=0 >[2009-11-03 14:05:14.383] - Operation add failed with > SyncML status=510 >–[2009-11-03 14:05:14.383] End of 'Process_Item' [->top] > [->enclosing] >[2009-11-03 14:05:14.383] processSyncOpItem: Error while > processing item, status=510 ...I see in the code (syncsession.cpp) that when "processSyncOpItem: Error while processing item" is logged, this inevitably also increases the fLocalItemsError counter (the one you get reported with the PEV_DSSTATS_E progress event at the end of the session. > One more question about the problem: what if the DB has temporary > problems, such that retrying the operation in the next sync has a chance > to succeed again? Is that something that could be done by returning a > suitable status to the peer, a) in the general case and b) when the peer > is also the Synthesis engine? You could of course return something indicating a temporary problem rather than just 510. This might make a difference with some servers, but I don't know. In my experience a implementation that does not just return 500 for all sorts of errors already counts as "advanced" :-( For a Synthesis based peer, all items that receive an error status () will be flagged and resent in the next session by default. You can switch this behaviour on the level using , and on a per-item level in the using SETRESEND(), where you can also check the status code and do other things like aborting a session or silently accept errors. 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] DB SaveDeviceInfo
Hi Hi Patrick, On Nov 12, 2009, at 19:20 , Patrick Ohly wrote: What is the intended use of the data stored with the DB SaveDeviceInfo() call? I kind of expected it to be opaque data as in SaveAdminData/LoadAdminData(), but then I noticed that there is no LoadDeviceInfo() call. It is intended for statistics - it just dumps out some info from the devInf. In our IOT server, we usually just store the REMOTE_DESC and REMOTE_INFO strings into fields of the device table (the one that gets queried at CheckDevice() for the last nonce) so we can show a description of the device along with it's ID in the session log browser. You can simply ignore that data if you have no use for it. If the device info is meant to be used by the DB, then its format would have to be documented somewhere. Is it documented and I just missed it? It seems that it is not documented :-( It should be, of course, as part of the SDK manual. IT IS DOCUMENTED in the current SDK manual, page 51. The correct name is Session_SaveDeviceInfo. As the fields themselves are subject to change and dependent on the server/client implementation, they are not explicitely described here. The analoguous functionality for the SQL level is documented in the config reference (). You can have a look at TPluginApiAgent::remoteAnalyzed() to see what info is dumped out to the plugin. Regards Beat -- --- Beat FORSTER Dipl. El. Ing. ETH Dipl. NDS ETHZ in Betriebswissenschaften Managing Partner beat.fors...@synthesis.ch Synthesis AG SyncML Server & Client Solutions Badenerstrasse 18, CH-8004 Zürich, Switzerland Tel (direct): +41 44 440 66 02 Fax:+41 44 440 66 04 email: i...@synthesis.ch web: http://www.synthesis.ch ---___ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
Re: [os-libsynthesis] DB SaveDeviceInfo
Hi Patrick, On Nov 12, 2009, at 19:20 , Patrick Ohly wrote: > What is the intended use of the data stored with the DB SaveDeviceInfo() > call? I kind of expected it to be opaque data as in > SaveAdminData/LoadAdminData(), but then I noticed that there is no > LoadDeviceInfo() call. It is intended for statistics - it just dumps out some info from the devInf. In our IOT server, we usually just store the REMOTE_DESC and REMOTE_INFO strings into fields of the device table (the one that gets queried at CheckDevice() for the last nonce) so we can show a description of the device along with it's ID in the session log browser. You can simply ignore that data if you have no use for it. > If the device info is meant to be used by the DB, then its format would > have to be documented somewhere. Is it documented and I just missed it? It seems that it is not documented :-( It should be, of course, as part of the SDK manual. The analoguous functionality for the SQL level is documented in the config reference (). You can have a look at TPluginApiAgent::remoteAnalyzed() to see what info is dumped out to the plugin. 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
