I believe that this rewrite of vdirsyncer is stable enough to warrant a stable release. Initially, I wanted to reach feature parity with the previous implementation before calling this stable, but I don’t think that’s the right mentality: the new version is stable enough for daily use. For use cases where features are missing, the previous version has to be used until those features have been ported. For other use cases, I recommend the new implementation already.
I am considering naming the new project vdirsyncer2, so that both can be
co-installed.
Right now my main blocker for an initial stable release is documentation: there’s some documentation, but not enough for a complete newcomer to figure out how to fully configure and use vdirsyncer. I can’t call this non-beta with the current state of the documentation.
Work on the documentation is ongoing, so that I can unblock a stable release. I decided to consolidate documentation into man pages, so that they are easily accessible offline in the same format as any other utility. Of course, I shall publish these same pages online too in HTML form.
Security considerations have been moved into these same man pages for better visibility. On the topic of security considerations, the ongoing security audit is coming to a close, and I am quite pleased with the results.
Splitting subprojects
I started writing vdirsyncer in Rust in a single repository along with its dependant libraries. This probably sped up initial development by a marginal amount, but as the project stabilised, this didn’t prove as convenient.
The main problem was when making backwards-incompatible changes to libdav. I
suddenly found that I couldn’t commit these changes without breaking vdirsyncer,
implying that I had to implement changes to multiple projects at once (and in a
single commit) even if those changes were not entirely related and had different
scopes.
This was not the first that this happened, and it became clear that as pieces mature, I want to be able to release dependencies before I deal with upgrading vdirsyncer for them.
I therefore split libdav and davcli into separate repositories. I
believe this also improves visibility for these projects, since they’re now more
than simply “a subdirectory in some other project”. Both of these are usable in
scenarios that don’t involve vdirsyncer at all.
Protections
I implemented protections for emptied collections in vdirsyncer. This means that if you delete a collection entirely, it won’t delete the collection on the other storage by default: it will show a warning and skip it instead.
While I prefer emptied collections to be emptied on the other side for my own
usage, this behaviour is somewhat dangerous and doesn’t feel like safe default.
So the protection is enabled by default, and users will have to opt-out of it
with the new on_empty = "sync" configuration directive.
Start-up performance
At start-up, vdirsyncer will no longer load pairs and storages that are not being synchronised (e.g.: if only a single pair was explicitly requested). This improves usability in two ways:
- If a disabled pair has some invalid configuration, that won’t block users from synchronising another pair.
- Vdirsyncer won’t prompt for credentials for storages that are not being operated upon.
Other minor tweaks
libdav, davcli and vdirsyncer now all properly handle situations where a
CalDav server has a home set with multiple entries. This is not a frequent
situation; most common servers use a single home set. But the edge case had
already come up, so it made sense to properly support it. It’s also well covered
by the CalDav specification.
Vdirsyncer now uses internal locks to avoid concurrent access to a same storage. This makes a difference for scenarios like storage A being synchronised with storage B and storage B being synchronised with storage C. The locks prevents both of these operations from running concurrently. Running them concurrently would often result in errors (although these errors would not result in data loss).
Several configuration errors now print the full path to the configuration path and clearer error messages. This helps understand what’s wrong when configuring vdirsyncer.
Username and password are now both optional, so vdirsyncer can be used in servers which don’t expect authentication.
Finally, I tested the project on OpenBSD. The objective was not only to ensure that vdirsyncer works well on this platform, but to also ensure good portability. Given the positive results, I don’t expect any issues on other BSDs or Unix-like platforms.