Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CalDAV "REPORT" highly bandwith-inefficient in the presence of VTIMEZONE items #243

Closed
svillemot opened this issue Dec 17, 2014 · 1 comment
Labels
Milestone

Comments

@svillemot
Copy link

svillemot commented Dec 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:

                        element.text = ical.serialize(
                            collection_tag, collection_headers,
                            collection_timezones + [item])

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.

@liZe liZe added the bug label Dec 18, 2014
@liZe liZe added this to the 1.0 milestone Dec 18, 2014
@liZe
Copy link
Member

liZe commented Apr 18, 2016

Fixed, now that timezones are stored in events.

@liZe liZe closed this as completed Apr 18, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants