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.