In the reply to a REPORT query, if there are VTIMEZONE in the calendar, Radicale transmits a lot of redundant data. More precisely, it resends all the VTIMEZONE entries for every VEVENT entry. This is highly inefficient.
For example, I have a 300kb ICS file which generates a REPORT reply of 26Mb! This is because it contains several VTIMEZONE entries, and those are repeated as many times as there are VEVENT entries. See this Syncevolution bug for the original discussion that led me to the discovery of this issue.
As I understand it, the problem is located in line 540 of xmlutils.py:
As you can see, all timezones are replicated for every item in the VCALENDAR.
I don't know why it was designed like that, but it looks highly inefficient, and creates very real problems (as can be seen in the Syncevolution bug). The right behavior IMHO would be to send back VTIMEZONEs only once in a given REPORT query, and only those that are used by VEVENTs reported back in the query.
Thanks for your work on this great software.
The text was updated successfully, but these errors were encountered:
svillemot commentedDec 17, 2014
In the reply to a REPORT query, if there are VTIMEZONE in the calendar, Radicale transmits a lot of redundant data. More precisely, it resends all the VTIMEZONE entries for every VEVENT entry. This is highly inefficient.
For example, I have a 300kb ICS file which generates a REPORT reply of 26Mb! This is because it contains several VTIMEZONE entries, and those are repeated as many times as there are VEVENT entries. See this Syncevolution bug for the original discussion that led me to the discovery of this issue.
As I understand it, the problem is located in line 540 of
xmlutils.py:As you can see, all timezones are replicated for every item in the VCALENDAR.
I don't know why it was designed like that, but it looks highly inefficient, and creates very real problems (as can be seen in the Syncevolution bug). The right behavior IMHO would be to send back VTIMEZONEs only once in a given REPORT query, and only those that are used by VEVENTs reported back in the query.
Thanks for your work on this great software.
The text was updated successfully, but these errors were encountered: