CalDAV/iCal libraries suboptimal

[yuwash]

The “double parsing” happening between python-caldav and ics is a bit suboptimal. The reason for the situation is

• Project started with only ics and CalDAV feature added later
• ics Todo class has explicit (albeit undocumented) interface for more attributes than python-caldav Todo class does.

Apparently it’s not possible to use python-caldav in a way that it only extracts the ical string, but not yet parsing it. The data attribute is only found on CalendarObjectResource layer e.g. Todo, but not on Calendar. The initial extraction of ical string from CalDAV is apparently happening within Calendar and not on DAVClient. The data is a complete VCALENDAR (containing just the one todo) rather than just the VTODO part. On the other hand ics only supports parsing complete calendars (or just individual lines) so this fits well together in a way.

Thus the current approach of getting Todo.data, making ics Calendars from each of them and then putting all the todos into one calendar seems like the only feasible way based on the available interfaces.

The VTodo class of the library VObject apparently has an even more complete set of explicitly interfaced attributes, but no documentation on this class found. Probably it works likes this:

vtodo.add('summary').value = "Some question"  # Untested!

As VObject was last updated 2018, perhaps not the best choice anyway though (compared to ics updated last week, python-caldav yesterday).