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

Feature: support icalendar objects #1

Closed
tobixen opened this issue Jan 24, 2017 · 1 comment
Closed

Feature: support icalendar objects #1

tobixen opened this issue Jan 24, 2017 · 1 comment
Milestone

Comments

@tobixen
Copy link
Member

tobixen commented Jan 24, 2017

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

@tobixen
Copy link
Member Author

tobixen commented Mar 9, 2019

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)

@tobixen tobixen added this to the Later milestone Mar 9, 2019
@tobixen tobixen modified the milestones: Later, v1.0 May 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant