Renaming items
Last month I mentioned a bug when items are renamed in a collection. After renaming an item, vdirsyncer would check the entire content on both sides during every single execution. I have now fixed this.
I have now renamed all my vcard files to match the name of the person they describe. This lets me use a terminal or file manager to easily visualise files. In the future, I’d like to write on a GUI vcard viewer, so I can just double click on vcard files when using a file manager.
I still haven’t released ab-tidy since it relies on yet-unreleased features of
Hare itself. I will tag a release once upstream ships a new release.
Properties
I have implemented synchronisation of properties. For calendars, these are DisplayName, Description, Colour and Order. The latter two are not formally standardised, but are widely supported de-facto standards.
For calendar stored in a vdir, these are supported by tools like khal and todoman. For calendars in CalDav, these properties are supported by a great deal of software, including Nextcloud, DAVx5, iOS’s calendars and reminders app.
Synchronising properties is subject to race conditions. For example, when synchronising, vdirsyncer will read the colour on both storages, and plan to copy the value from one storage onto the other. If another process changed the colour of the target storage in the meantime, that value would be lost. This is really unlikely to happen in practice, and the data loss is minimal (in this example, only the newly applied colour is lost).
This issue is due to limitations of the CalDav protocol, so this is unlikely to change in future. I will simply document it well and move on.
Reading Etags
Previously the Storage abstraction didn’t always return an Etag (because
CalDav servers sometimes don’t return an Etag). I have changed this logic to
always return an Etag, or an error if a race condition occurred reading it.
This has simplified logic during synchronisation and was required in order to handle renamed items.
Focus
I’ve been focusing a lot on actually completing development milestones rather than attempting to polish everything into a perfect state (nothing is really perfect anyway). This has worked pretty well so far, and having a working version quickly allows some level of polish. As long as no bugs are introduced, I’m fine with keeping this “good enough” until there is an actual need to improve them.
Memory usage is a good example; I’ve been focusing a lot on not using too much memory but vdirsyncer uses about 16MiB of ram when synchronising my collections 3500 items. This could be better, but it’s a bit of an unnecessary improvement at this stage.
Properties for items
I’ve kept properties for items scope for quite some time now, but I am concerned this might have been a mistake. Calendars and contacts don’t have properties for items, they only have properties for collections. This feature was only in scope for potentially synchronising emails in future (where “properties” would basically be “flags”).
This has added some complexity that I’m not certain will ever pay off. Synchronisation of properties currently only works for collections, since dealing with the added complexity of item-properties would have substantially delayed properties for calendars and address books.
Documentation
I have split the user documentation, developer documentation and contributor documentation. This provides clearer starting points for each mode of usage.
The user documentation still needs more work, especially configuring and setting up from scratch.
Vdir safety checks
The vdir (filesystem) storage had a lot of pending FIXME comments regarding
security. Most of them were to prevent malicious input from writing elsewhere
in the filesystem.
I have since cleared all of those and implemented the appropriate checks.
That’s it for this month. Cheers!