Re: [os-libsynthesis] empty anchor or dummy string
On Wed, 2009-08-12 at 19:20 +0100, Lukas Zeller wrote: > On Aug 12, 2009, at 19:27 , Patrick Ohly wrote: > > I think the logic is the other way around: if first sync, then clear > > the > > anchor. At least that is what I patched in the code. "syncevolution" > > still reports "first time sync" despite the patch, so I don't think it > > broke anything. We should remove it nevertheless - after 0.9, which I > > tagged and compiled today. > > I didn't say you broke something :-) No, but that was my fear because the code is in SyncEvolution 0.9 ;-) -- 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] empty anchor or dummy string
Hi Patrick, On Aug 12, 2009, at 19:27 , Patrick Ohly wrote: Anyway, ScheduleWorld can handle that now, so it is safe to not merge the patch and remove it also in our git repo. ok, simple solution :-) Reason is that these variables have the semantic meaning of "no anchor" = "empty string". Changing that could mess up code testing these for emptyness e.g. to detect first-time-sync status (I haven't checked if that is really used somewhere, but it would be OK to do so). I think the logic is the other way around: if first sync, then clear the anchor. At least that is what I patched in the code. "syncevolution" still reports "first time sync" despite the patch, so I don't think it broke anything. We should remove it nevertheless - after 0.9, which I tagged and compiled today. I didn't say you broke something :-) I just know that all code around anchors was written with the idea of "no anchor" = "empty string" (because I did write it), so to be sure I had to review the complete codebase (especially including the older, non-OS parts) to make sure it won't have an impact. Even if I think it most *probably* would not hurt. 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] empty anchor or dummy string
On Wed, 2009-08-12 at 17:40 +0100, Lukas Zeller wrote: > I just saw your patch: > > > slow sync: avoid empty anchors, that confuses ScheduleWorld > > > > This patch fixes http://bugzilla.moblin.org/show_bug.cgi?id=4703, > > "ScheduleWorld: delete on server can not sync to client (after doing > > slow sync)". > > > > Somehow the ScheduleWorld server has problems with . > > Saving the mapping on the server fails in that case. Mark called > > an empty anchor string invalid. > > > > I don't agree with that and think this issue should be fixed on > > the server, but as it can be worked around easily (and perhaps > > more quickly) on the client side, here's the patch for it. > > > > Instead of "" it now uses "no local anchor". For symmetry reasons > > (not required to solve this problem) the last remote anchor is > > set to "no remote anchor". > > I'm a bit confused, because I don't see how an empty can > be created at all. The tag is optional within , and it > is therefore created using newPCDataOptString() in newMetaAnchor(), > which does not create the element at all when the input string > is missing or empty. So IMHO the engine NEVER sends a . Not sure. Mark mentioned as the root cause; I don't remember whether I checked the outgoing messages myself. But I could reproduce the problem and setting the anchor as in the patch fixed it. > Still, if the problem is that Scheduleworld also cannot handle a > missing tag, Perhaps that was the problem. Anyway, ScheduleWorld can handle that now, so it is safe to not merge the patch and remove it also in our git repo. > Reason is that these variables have the semantic meaning of "no > anchor" = "empty string". Changing that could mess up code testing > these for emptyness e.g. to detect first-time-sync status (I haven't > checked if that is really used somewhere, but it would be OK to do so). I think the logic is the other way around: if first sync, then clear the anchor. At least that is what I patched in the code. "syncevolution" still reports "first time sync" despite the patch, so I don't think it broke anything. We should remove it nevertheless - after 0.9, which I tagged and compiled today. -- 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
[os-libsynthesis] empty anchor or dummy string
Hi Patrick, I just saw your patch: slow sync: avoid empty anchors, that confuses ScheduleWorld This patch fixes http://bugzilla.moblin.org/show_bug.cgi?id=4703, "ScheduleWorld: delete on server can not sync to client (after doing slow sync)". Somehow the ScheduleWorld server has problems with . Saving the mapping on the server fails in that case. Mark called an empty anchor string invalid. I don't agree with that and think this issue should be fixed on the server, but as it can be worked around easily (and perhaps more quickly) on the client side, here's the patch for it. Instead of "" it now uses "no local anchor". For symmetry reasons (not required to solve this problem) the last remote anchor is set to "no remote anchor". I'm a bit confused, because I don't see how an empty can be created at all. The tag is optional within , and it is therefore created using newPCDataOptString() in newMetaAnchor(), which does not create the element at all when the input string is missing or empty. So IMHO the engine NEVER sends a . Still, if the problem is that Scheduleworld also cannot handle a missing tag, I'd favor a patch that would insert a dummy just when creating the actual SyncML command (i.e. at the points where newMetaAnchor() is called), and not touch fLastLocalAnchor or fLastRemoteAnchor. Reason is that these variables have the semantic meaning of "no anchor" = "empty string". Changing that could mess up code testing these for emptyness e.g. to detect first-time-sync status (I haven't checked if that is really used somewhere, but it would be OK to do so). 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
