On Sat, 2009-12-12 at 13:38 +0000, Lukas Zeller wrote: > Hi Patrick, > > On Dec 11, 2009, at 15:15 , Patrick Ohly wrote: > > > On Fri, 2009-12-11 at 14:55 +0100, Patrick Ohly wrote: > >> One possibility is to use scripting. In a script for a datatstore I > >> might be able to use ABORTDATASTORE(). > > > > Related to this one other question: which status could should I use to > > indicate the the datastore was excluded from the sync intentionally? > > > > I remember vaguely that we discussed reserving a range of the uInt16 > > TSyError codes for use by the application. I could pick an error code in > > that range, except that I don't find in enum TSyErrorEnum/syerror.h what > > that range is. Can someone refresh my memory here? Did we only talk > > about it without actually applying a patch? > > I thought you had applied it, but I fail to find it now.
Same with me, on both. Must have been lost again later on. > > While talking about this, I didn't understand this comment in the > > syerror.h file: > > > > /** local codes signalling SyncML status are shown as > > LOCAL_STATUS_CODE+<SyncML-Statuscode> */ > > LOCAL_STATUS_CODE = 10000 > > > > Does that mean that everything in the range >=10000 is a SyncML status > > code after subtracting 10000? > > Not everything, but up to about 10599. The prefix is used to > distinguish real SyncML status codes received as such (from the > remote) from using the same codes for locally generated errors. Does that mean that locally generated errors, for example from the DB layer, should be in that range? I don't find in the src/sysync source where LOCAL_STATUS_CODE might get added to local status codes, and the example code (like text_db) returns "normal" errors, like DB_Error = 510. > I'd suggest to put an app specific range to 22000..22999, as we have > the also app-specific cURL block at 21000 and the Linux Signals block > at 20500 already. I'm adding both to syerror.h in moblin.org for you to merge at the next occasion. -- 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 [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
