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 <last></last>. > > 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 <last></last> can > be created at all. The <last> tag is optional within <anchor>, and it > is therefore created using newPCDataOptString() in newMetaAnchor(), > which does not create the <last> element at all when the input string > is missing or empty. So IMHO the engine NEVER sends a <last></last>.
Not sure. Mark mentioned <last></last> 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 <last> 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
