You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today we have a dependency on vobjects, and we've discussed a bit forth and back if we could get rid of this dependency. It was most pressing in 2015 and early 2016 as the vobjects development was frozen and the official vobjects release didn't support python3. Today this is a non-pressing issue, but there is still a wish out there that we'd support icalendar as well. Even my calendar-cli tool is importing and using the icalendar library, not vobjects.
Perhaps the best way to do it would be to let the current "instance" property yield a vObject (for compatibility reasons), while we make new methods "toVObject" and "toIcalendar" methods (or similar). Imports of the libraries should be done only when they are needed.
I believe some of the task management code I wrote actually depends on the instance to work. This complicates things a bit.
This is a non-urgent task, as long as there aren't any proper (backward-compatible) pull requests, I probably won't bother prioritizing it.
There exists one or two pull requests already, but none of them are backward-compatible as far as I know.
I've taken one step in the right direction, I've renamed "instance" to "vobject_instance", and made "instance" point to "vobject_instance" for legacy reasons. I've also delayed the object instantiation (ref #43), so that the vobject logic will only be called on when it's needed.
My next ideas:
fix an "icalendar_instance" that returns an icalendar instance. As edits to the instance should be honored, only one instantiated object can be attached to the caldav object - if obj._vobject_instance is not None, then first set obj._data=obj._vobject_instance.serialize() and then set obj._vobject_instance to None before setting obj._icalendar_instance, and vice versa. (This won't be very optimal if both object types are frequently accessed, but that shouldn't really happen)
Do some more research on it - is icalendar really better? The main argument for moving to icalendar was that vobject didn't support python3 and wasn't maintained. I also tried looking a bit into vobject myself to fix some bugs and such - but I found a rabbit hole - I didn't want to go deeper there. At least the maintainer situation has improved as far as I can understand ... maybe things aren't that bad anymore?
If we decide to ditch vobject, then all code accessing the instance should be rewritten to support icalendar, the import of vobject should be done if/when someone calls on the vobject_instance, and vobject should be marked an optional dependency. (test code still needs to exercise this code path)
Today we have a dependency on vobjects, and we've discussed a bit forth and back if we could get rid of this dependency. It was most pressing in 2015 and early 2016 as the vobjects development was frozen and the official vobjects release didn't support python3. Today this is a non-pressing issue, but there is still a wish out there that we'd support icalendar as well. Even my calendar-cli tool is importing and using the icalendar library, not vobjects.
Perhaps the best way to do it would be to let the current "instance" property yield a vObject (for compatibility reasons), while we make new methods "toVObject" and "toIcalendar" methods (or similar). Imports of the libraries should be done only when they are needed.
I believe some of the task management code I wrote actually depends on the instance to work. This complicates things a bit.
This is a non-urgent task, as long as there aren't any proper (backward-compatible) pull requests, I probably won't bother prioritizing it.
See also https://bitbucket.org/cyrilrbt/caldav/issues/41 and https://bitbucket.org/cyrilrbt/caldav/pull-requests/17/replace-vobject-by-icalendar
The text was updated successfully, but these errors were encountered: