On Wed, 2010-04-14 at 20:29 +0100, Ahmed Guellil wrote: > In the compatibility section on syncevolution's website, you wrote : > > > Of the servers listed here, SyncEvolution is regularly tested with > > ScheduleWorld, Funambol, Google and Synthesis server, so, the > > information about known problems with them is also more detailed. > > Not listing problems with other servers does not mean they do not > > exist... If you have tested with a server not listed here or would > > like to add further information, then your updates to this page, > > sent to email, are highly appreciated. > so I would like to talk about the Memotoo server.
Let me copy Thomas Pequet, maintainer of Memotoo. > I didn't see any problems concerning the todos, memos, or addressbook > (just a few modifications during sync for the contacts phone numbers > (none->home/work)). > > A few days ago, I tried to synchronize my calendar that way, under > Debian Lenny : > > syncml native client syncevolution (0.9.2+1.0beta2a-2) > N79 <-----------------> Memotoo <-------------------> Evolution > (2.22.3.1-1) > two-way two-way > > It seems that there is a problem about detached recurrences. I read > your article on this subject, and to be fair, I'm not an expert, but I > run some tests on my workstation and here is what I found : > - a detached recurrence on the N79 is well synchronized with Memotoo. > There is no duplicate. > - a detached recurrence on the Memotoo is well synchronized with the > N79. There is no duplicate. > - a detached recurrence on Memotoo is duplicated on Evolution but not > on Memotoo, even after resync. In iCalendar 2.0, detached recurrences are linked to the recurring event via their UID. If there is a VEVENT with UID=<foo> and RECURRENCE-ID=<date>, then the main event is not to be displayed on <date>, only the detached recurrence is. In addition, some software also adds an EXDATE exception in the main event for <date>. I don't think this is required. My theory is that this fails because Memotoo does not support the UID property (known limitation) *and* the software which created the recurring event did not include an exception. Let's test... hmm, I don't find a way to modify one particular occurrence on the Memotoo web interface, so I cannot test the Memotoo->Evolution case. Ahmed, I need you help there. Can you save both the main event and the detached recurrence in Evolution and attach it to your reply? Please remove sensitive information. > - a detached recurrence on Evolution is duplicated on Memotoo but not > on Evolution, even after resync. This I can reproduce, and it fits my theory. When modifying one recurrence, Evolution 2.38.3 did not update the recurring event, so all that Memotoo is sent is one VEVENT with UID and RECURRENCE-ID. It then ignores the UID and thus displays the main event and the detached recurrence. Thomas, does that make sense? Any suggestions how this could be fixed? > I think it's a conflict problem but I don't know how to resolve it. > From what I've heard, it seems that the events modifications are not > time stamped, so syncevolution has no means to discover which one is > to save and which one should be deleted, so it creates duplicates not > to loose data. But I don't know. Actually, I almost never modify the > same event with the two clients before synchronizing. Maybe the events > aren't the same anyway, maybe it's because of syncevolution, or maybe > evolution (too old version ?). Good guess, but that's not it. > It's a bit disturbing because I have a lot of professional meetings > and after each one I wrote systematically a description about it. I > also modify or cancel some regularly, which means I end with a lot of > duplicates. > > So I would be pleased if you help me (and maybe others) to solve this > problem. But I know you're a busy guy. -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
