2:29 p.m.
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
<mailto:patrick.ohly@gmx.de>, are highly appreciated.
so I would like to talk
about the Memotoo <https://www.memotoo.com/> server.
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.
- a detached recurrence on Evolution is duplicated on Memotoo but not on
Evolution, even after resync.
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 ?).
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.
Thanks.
Ahmed Guellil
Nantes, France
4:06 a.m.
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.
6:52 a.m.
New subject: [SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo (was: Re: A synchronization server named Memotoo)
On Thu, 2010-04-15 at 11:06 +0200, Patrick Ohly wrote:
On Wed, 2010-04-14 at 20:29 +0100, Ahmed Guellil wrote:
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.
This is still relevant. What I don't understand is how Memotoo avoids
displaying the recurring event on the day of the detached recurrence. If
it is via EXDATE, then it should also work in Evolution.
Unless Memotoo never sends the exception... perhaps you can modify the
recurring event, sync with Evolution using a higher log level
("syncevolution --run --sync-property loglevel=4 memotoo"), then check
the log ("syncevolution --print-sessions memotoo") and quote the
incoming VEVENT as it is sent by Memotoo?
> - 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?
We've had the same problem with Funambol. At that time I didn't have an
idea, but after writing down the explanation above and thinking some
more about it, here's something that might work: when a new VEVENT gets
added in Evolution with RECURRENCE-ID for an existing, unmodified
recurring event, then modify the recurring event by adding an exception.
Then sync both the main event and the child to the server.
Evolution doesn't do this because iCalendar 2.0 doesn't require it, but
as workaround for servers with incomplete iCalendar 2.0 semantic (like
Memotoo and Funambol) it is necessary and should have no negative side
effects (well, except for more complicated client code and slightly
increased network traffic).
--
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.
6:40 a.m.
New subject: [SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo
Hi all
I can not arrive to reproduce the problem: the rule on Memotoo is
successfully sent to Evolution and there is no duplicate.
Ahmed, if you are french, send me an email with the problem in french,
my be I will better understand what is wrong.
Thomas
Patrick Ohly a écrit :
On Thu, 2010-04-15 at 11:06 +0200, Patrick Ohly wrote:
> On Wed, 2010-04-14 at 20:29 +0100, Ahmed Guellil wrote:
> 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.
>
This is still relevant. What I don't understand is how Memotoo avoids
displaying the recurring event on the day of the detached recurrence. If
it is via EXDATE, then it should also work in Evolution.
Unless Memotoo never sends the exception... perhaps you can modify the
recurring event, sync with Evolution using a higher log level
("syncevolution --run --sync-property loglevel=4 memotoo"), then check
the log ("syncevolution --print-sessions memotoo") and quote the
incoming VEVENT as it is sent by Memotoo?
>> - 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?
>
We've had the same problem with Funambol. At that time I didn't have an
idea, but after writing down the explanation above and thinking some
more about it, here's something that might work: when a new VEVENT gets
added in Evolution with RECURRENCE-ID for an existing, unmodified
recurring event, then modify the recurring event by adding an exception.
Then sync both the main event and the child to the server.
Evolution doesn't do this because iCalendar 2.0 doesn't require it, but
as workaround for servers with incomplete iCalendar 2.0 semantic (like
Memotoo and Funambol) it is necessary and should have no negative side
effects (well, except for more complicated client code and slightly
increased network traffic).
5:34 p.m.
New subject: [SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo
On Wed, 2010-04-21 at 13:40 +0200, Thomas Pequet wrote:
I can not arrive to reproduce the problem: the rule on Memotoo is
successfully sent to Evolution and there is no duplicate.
I can help with testing this too, because I have noticed the same
behavior.
I created a new recurring event on Evolution. Synced to memotoo.
Modified one instance of the event on Evolution, adding a location and
modified the description. Synced to memotoo. Here is the output of the
sync session:
Local data changes to be applied to server during synchronization:
*** calendar ***
after last sync | current data
removed since last sync <
added since last sync
-------------------------------------------------------------------------------
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
SUMMARY:test recurrence SUMMARY:test recurrence
CLASS:PUBLIC CLASS:PUBLIC
DESCRIPTION:event modified: set a l
ocation
DTEND;TZID=America/Los_Angeles:2010
0511T093000
DTSTART;TZID=America/Los_Angeles:20
100511T090000
LOCATION:set a location
RECURRENCE-ID;TZID=America/Los_Ange
les:20100511T090000
SEQUENCE:3
TRANSP:OPAQUE
UID:20100506T221204Z-2533-1000-1-11
@biancone
BEGIN:VALARM
ACTION:DISPLAY
DESCRIPTION:test recurrence
TRIGGER;RELATED=START;VALUE=DURAT
ION:-PT15M
X-EVOLUTION-ALARM-UID:20100506T22
1318Z-3164-1000-1-96@biancone
END:VALARM
END:VEVENT
BEGIN:VTIMEZONE
TZID:America/Los_Angeles [...]
END:VTIMEZONE
END:VCALENDAR
-------------------------------------------------------------------------------
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:test recurrence
CLASS:PUBLIC
DESCRIPTION:initial evet
DESCRIPTION:initial evet
DTEND;TZID=America/Los_Angeles:2010 DTEND;TZID=America/Los_Angeles:2010
0510T093000 0510T093000
DTSTART;TZID=America/Los_Angeles:20 DTSTART;TZID=America/Los_Angeles:20
100510T090000 100510T090000
RRULE:COUNT=4;FREQ=DAILY RRULE:COUNT=4;FREQ=DAILY
SEQUENCE:2 SEQUENCE:2
TRANSP:OPAQUE TRANSP:OPAQUE
UID:20100506T221204Z-2533-1000-1-11 UID:20100506T221204Z-2533-1000-1-11
@biancone @biancone
BEGIN:VALARM BEGIN:VALARM
ACTION:DISPLAY ACTION:DISPLAY
DESCRIPTION:test recurrence DESCRIPTION:test recurrence
TRIGGER;RELATED=START;VALUE=DURAT TRIGGER;RELATED=START;VALUE=DURAT
ION:-PT15M ION:-PT15M
X-EVOLUTION-ALARM-UID:20100506T22 X-EVOLUTION-ALARM-UID:20100506T22
1222Z-3164-1000-1-94@biancone 1222Z-3164-1000-1-94@biancone
END:VALARM END:VALARM
END:VEVENT END:VEVENT
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America/Los_Angeles [...] TZID:America/Los_Angeles [...]
END:VTIMEZONE END:VTIMEZONE
END:VCALENDAR END:VCALENDAR
-------------------------------------------------------------------------------
On memotoo server I see two events (see attached screenshot): one is a
series of events, the other is an isolated one.
On memotoo site I modified the modified recurring event (the one that
shows up as duplicate in memotoo and synced. On Evolution I get 4
events, but the first one of the series is removed and two are
duplicated in the same day.
Changes applied to client during synchronization:
*** calendar ***
before sync | after sync
removed during sync <
added during sync
-------------------------------------------------------------------------------
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
SUMMARY:Test #2 SUMMARY:Test #2
CLASS:PUBLIC CLASS:PUBLIC
DESCRIPTION:Recurring and no modifi | DESCRIPTION:changed time and descri
cation | ption
DTEND;TZID=America/Los_Angeles:2010 DTEND;TZID=America/Los_Angeles:2010
0510T113000 | 0511T120000
DTSTART;TZID=America/Los_Angeles:20 DTSTART;TZID=America/Los_Angeles:20
100510T110000 | 100511T113000
RRULE;X-EVOLUTION-ENDDATE=20100513T | RECURRENCE-ID;TZID=America/Los_Ange
180000Z:COUNT=4;FREQ=DAILY | les:20100511T110000
SEQUENCE:2 | SEQUENCE:3
TRANSP:OPAQUE TRANSP:OPAQUE
UID:20100506T222253Z-2533-1000-1-13 UID:20100506T222253Z-2533-1000-1-13
@biancone @biancone
BEGIN:VALARM BEGIN:VALARM
ACTION:DISPLAY ACTION:DISPLAY
DESCRIPTION:Test #2 DESCRIPTION:Test #2
TRIGGER;RELATED=START;VALUE=DURAT TRIGGER;RELATED=START;VALUE=DURAT
ION:-PT15M ION:-PT15M
X-EVOLUTION-ALARM-UID:20100506T22 X-EVOLUTION-ALARM-UID:20100506T22
2327Z-3164-1000-1-150@biancone | 2711Z-3164-1000-1-154@biancone
END:VALARM END:VALARM
END:VEVENT END:VEVENT
BEGIN:VTIMEZONE BEGIN:VTIMEZONE
TZID:America/Los_Angeles [...] TZID:America/Los_Angeles [...]
END:VTIMEZONE END:VTIMEZONE
END:VCALENDAR END:VCALENDAR
-------------------------------------------------------------------------------
BEGIN:VCALENDAR BEGIN:VCALENDAR
VERSION:2.0 VERSION:2.0
BEGIN:VEVENT BEGIN:VEVENT
SUMMARY:Test #2 SUMMARY:Test #2
CLASS:PUBLIC CLASS:PUBLIC
DESCRIPTION:changed time and descri DESCRIPTION:changed time and descri
ption | ption.
DTEND;TZID=America/Los_Angeles:2010 | DTEND:20100511T190000Z
0511T120000 | DTSTART:20100511T183000Z
DTSTART;TZID=America/Los_Angeles:20 | LOCATION:Via Adolfo Ferrata\, 27100
100511T113000 | Pavia PV\, Italy
RECURRENCE-ID;TZID=America/Los_Ange <
les:20100511T110000 <
SEQUENCE:3 <
TRANSP:OPAQUE <
UID:20100506T222253Z-2533-1000-1-13 UID:20100506T222253Z-2533-1000-1-13
@biancone @biancone
BEGIN:VALARM BEGIN:VALARM
ACTION:DISPLAY ACTION:DISPLAY
DESCRIPTION:Test #2 | TRIGGER;VALUE=DURATION:-PT15M
TRIGGER;RELATED=START;VALUE=DURAT <
ION:-PT15M <
X-EVOLUTION-ALARM-UID:20100506T22 X-EVOLUTION-ALARM-UID:20100506T22
2711Z-3164-1000-1-154@biancone | 2903Z-2533-1000-1-14@biancone
END:VALARM END:VALARM
END:VEVENT END:VEVENT
BEGIN:VTIMEZONE <
TZID:America/Los_Angeles [...] <
END:VTIMEZONE <
END:VCALENDAR END:VCALENDAR
-------------------------------------------------------------------------------
I have the logs at level 4, in case you're interested. Let me know.
cheers
stef
--
Funambol :: Open Source Mobile Cloud Sync and Push Email
Community manager :: https://www.forge.funambol.org
Follow the tweets: http://twitter.com/funambol
Funambol Identi.ca group: http://identi.ca/group/funambol
6:21 a.m.
New subject: [SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo
On Thu, 2010-05-06 at 23:34 +0100, Stefano Maffulli wrote:
On Wed, 2010-04-21 at 13:40 +0200, Thomas Pequet wrote:
> I can not arrive to reproduce the problem: the rule on Memotoo is
> successfully sent to Evolution and there is no duplicate.
I can help with testing this too, because I have noticed the same
behavior.
I created a new recurring event on Evolution. Synced to memotoo.
Modified one instance of the event on Evolution, adding a location and
modified the description. Synced to memotoo. Here is the output of the
sync session:
[...]
On memotoo server I see two events (see attached screenshot): one is
a
series of events, the other is an isolated one.
On memotoo site I modified the modified recurring event (the one that
shows up as duplicate in memotoo and synced. On Evolution I get 4
events, but the first one of the series is removed and two are
duplicated in the same day.
I'm not entirely sure why you get 4 events, but I think I can reproduce
the problem and have a fix. Tracked as
http://bugs.meego.com/show_bug.cgi?id=1916
What happens is that Memotoo sends us a VEVENT as update which has
neither UID nor RECURRENCE-ID. SyncEvolution already used to add back
the UID, but didn't do that for the RECURRENCE-ID. What thus happens is
that the updated VEVENT overwrites the original, recurring VEVENT,
instead of overwriting the single instance.
Normally I would expect the Synthesis engine to handle this, by
retrieving the existing item and updating individual fields. However,
this depends on knowing supported fields. Memotoo does not send CtCap
information and therefore this mechanism is skipped.
The same problem also occurs with the Funambol server, I just checked.
It also doesn't send CtCap. Stefano, why is that? Shouldn't it always
send that?
--
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.
3:20 a.m.
New subject: [SyncEvolution] UID/RECURRENCE-ID / detached recurrence / Funambol / Memotoo (was: Re: A synchronization server named Memotoo)
On Sat, 2010-04-17 at 13:52 +0200, Patrick Ohly wrote:
We've had the same problem with Funambol. At that time I
didn't have an
idea, but after writing down the explanation above and thinking some
more about it, here's something that might work: when a new VEVENT gets
added in Evolution with RECURRENCE-ID for an existing, unmodified
recurring event, then modify the recurring event by adding an exception.
Then sync both the main event and the child to the server.
Created an issue to track this:
http://bugzilla.meego.com/show_bug.cgi?id=1180
--
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.
3916
days inactive
3942
days old
syncevolution@synevolution.org
6 comments
4 participants
participants (4)
-
Ahmed Guellil -
Patrick Ohly -
Stefano Maffulli -
Thomas Pequet