--- Comment #7 from Patrick Ohly <patrick.ohly(a)gmx.de> ---
(In reply to Sébastien Villemot from comment #6)
Actually radicale does not use libical,
You are right. I forgot that radicale is just fudging proper CalDAV semantics
by doing text manipulations (radicale/ical.py).
so I'm not sure to understand the
connection to the libical change that you mentioned.
The large VTIMEZONE definitions in the log look exactly like the ones generated
by the modified libical. If Radicale does not generate them, then it must have
received them from a client (perhaps even SyncEvolution).
Current SyncEvolution should send the smaller VTIMEZONEs with just one entry
for summer time and one for winter time.
However it is clear that the problem is linked to timezones. I cleant
calendar.ics file by removing all the custom timezones (those with
"freeassociation.sourceforge.net"), and now the REPORT request transfers
1.1Mb (instead of 26Mb previously). This is still 3 times as big as the
whole calendar.ics, but it is nevertheless much better.
Removing them entirely might lead to missing time zone information in the items
sent to clients. It might not matter in practice because clients (including
SyncEvolution) often look at the TZID first to match it with an existing local
Looking at the log, it still looks that the spurious traffic comes
timezone information that is repeated for every VEVENT entry.
That's worth discussing with Radicale devs. I don't know how they currently
decide which VTIMEZONEs need to be inserted into the individual items. If they
include *all* of them, then it's not surprising that there is significant
overhead once a calendar contains several different time zone definitions.
You are receiving this mail because:
You are on the CC list for the bug.