Replaced vobject by icalendar. #28
Conversation
|
You're not the first one to send such a pull request, the problem with this is the need to keep things backward compatible. It's been a while since I looked into this, but I believe the icalendar and vObject libraries are not completely compatible. |
|
I understand your concerns but in my case (and I guess it was the same for others if you already received such a PR), it's just unusable with vobject... That might be a huge refactoring but what about a backend mechanism? Let people choose vobject and icalendar? |
|
Letting people choose between icalendar and vobject somehow while also marking vobject as deprecated in the documentation. Perhaps finding new names for the methods giving access to the icalendar objects. Perhaps importing the vobject library only when needed (since it is becoming an optional dependency) |
Gives a new propery calendar_item.icalendar_instance. The .instance property will still give a vobject, and icalendar is not listed as a requirement yet - icalendar module will be imported late, when needed. In version 1.0, probably this will be reversed, with vobject being an optional dependency and icalendar being used internally. This commit also changes the way data is stored, the new logic ensures data is stored authoratively either in _data, _vobject_instance or _icalendar_instance. So, mess up .e. with event.vobject_instance.vevent.due.value and it will be refleted in event.data. It wasn't so earlier, but during the save operation, the instance would be given priority. Resolves #1 - references #97 #92 #3 and #28
|
I'll close this pull request, as the master branch now supports icalendar objects |
I recently added a calendar plugin to the project I work on (Modoboa, https://github.com/modoboa/modoboa-radicale) and during my tests, I realized vobject was extremely slow to parse recurring rules. Since I'm not the first one to report this behaviour, I've replaced it by icalendar which offers better performance.