http://bugs.meego.com/show_bug.cgi?id=10265
--- Comment #12 from alainlux <meego(a)misc.lka.org.lu> 2010-11-22 04:11:50 PST ---
(In reply to comment #11)
The logs on the server side would be more interesting than the logs
from the
client side.
Yes, that's what I figured...
But before we go there, let's try to simplify the testing by
focusing on the
core aspect which fails here: change detection on the server side. This can be
tested on the server side with "syncevolution --status <client config name>
calendar", without running a sync.
Indeed, this simplifies a lot.
Indeed, the first run after change says:
syncevolution --status n900 calendar
[INFO] addressbook:
inactive
[INFO] todo: inactive
[INFO] memo: inactive
[INFO] Local item changes:
+---------------------------------------------|-----------------------+
| Source | NEW | MOD | DEL |TOTAL|
+---------------------------------------------+-----+-----+-----+-----+
| calendar | 0 | 0 | 0 | 159 |
+---------------------------------------------+-----+-----+-----+-----+
| start Mon Nov 22 12:45:18 2010, duration 0:00min |
+---------------------------------------------+-----+-----+-----+-----+
Local data changes to be applied remotely during synchronization:
*** calendar ***
no changes
... and the next one says:
[INFO] addressbook: inactive
[INFO] todo: inactive
[INFO] memo: inactive
[INFO] Local item changes:
+---------------------------------------------|-----------------------+
| Source | NEW | MOD | DEL |TOTAL|
+---------------------------------------------+-----+-----+-----+-----+
| calendar | 1 | 0 | 0 | 160 |
+---------------------------------------------+-----+-----+-----+-----+
| start Mon Nov 22 12:45:27 2010, duration 0:00min |
+---------------------------------------------+-----+-----+-----+-----+
Local data changes to be applied remotely during synchronization:
*** calendar ***
after last sync | current data
removed since last sync <
added since last sync
-------------------------------------------------------------------------------
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:zozo
DTEND;TZID=Europe/Paris:20101123T14
0000
DTSTART;TZID=Europe/Paris:20101123T
130000
UID:e0d466e6-b1ec-49fc-bea9-7d94ab6
ae71e
X-EVOLUTION-CALDAV-ETAG:"347697bf1a
f83454521ed8f27c82f0a3"
X-EVOLUTION-CALDAV-HREF:/caldav/cal
dav.php/alain/home/e0d466e6-b1ec-49
fc-bea9-7d94ab6ae71e.ics
END:VEVENT
BEGIN:VTIMEZONE
TZID:Europe/Paris
X-LIC-LOCATION:Europe/Paris
BEGIN:DAYLIGHT
DTSTART:19700328T020000
RRULE:BYDAY=-1SU;BYMONTH=3;FREQ=Y
EARLY
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19701031T030000
RRULE:BYDAY=-1SU;BYMONTH=10;FREQ=
YEARLY
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
END:VCALENDAR
-------------------------------------------------------------------------------
As soon as you add a new event in CalDAV, the command should show a) one item
added in the statistics table and b) the new item data in the diff.
Only happens after I run syncevolution --status the second time after the
change.
I have a theory: adding the event does not show up immediately via
libecal,
which is what SyncEvolution is using. Sometime later, EDS notices and the event
appears. In the example logs, that happened to be between starting and
completing the first sync run.
Does that sound plausible?
Hmmm, not really... It doesn't seem to be timing dependant... even waiting
several minutes before the first syncevolution still keeps the same behavior...
If that is the explanation, then I see only one solution: write a native CalDAV
backend instead of relying on the EDS bridge. There is no call which tells
libecal to refresh the data immediately, so there will always be this delay.
Indeed, this is what seems to be happening: syncevolution connects to Evolution
Data Server, which only seems to poll caldav _after_ the connection (or at
least _after_ feeding its state to syncevolution).
So, a workaround would be to run syncevolution --status first (on PC), and only
then run the syncevolution client from the mobile.
Syncevolution seems to communicate with EDS using DBUS. Maybe there is one DBUS
command which causes EDS to "refresh" itself from caldav which is being sent
too late? Is there a "tcpdump"-like tool for DBUS, so that I could find out
what happens?
--
Configure bugmail:
http://bugs.meego.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.