‹ back home

vdirsyncer status update, July 2023

2023-07-17 #status-update #vdirsyncer #open-source

CardDav support

This month I’ve worked on missing CardDav support in existing libraries.

Regarding libdav itself, this has helped tidy up parts of the code that are shared between the CalDav and CardDav. This wasn’t very complicated; the latter is very similar to the former, so it was just making sure that all of the little differences were tweaked currently. The recent rewrite of the parsers helped a lot since I could reuse most of the code from the CalDav implementation.

I also have in mind eventually improving the libdav’s WebDav client to make it more usable as a stand-alone client. Even though that was not originally in scope, I have some other projects in mind that could use this in future, and a generic WebDav client could definitely be useful in the Rust ecosystem.

Regarding vstorage, this is the first storage that only handles items of a type that are not calendars, which mostly confirms that the design of the Storage types fits well.

Finally, I implemented live tests for CardDav servers. The code for live tests is still “just okay”, and implementing CardDav consisted mostly of copying a few tests and tweaking the bits that are different.

I’m happy to say that these tests yielded very positive results. Tests pass with all the same servers I’d been testing so far. The only small issues that I’ve found are essentially the same issues that I found for CalDav on these servers (I have reported most of them, but have a few still pending). To be clear: these issues are merely scenarios where servers don’t behave entirely as expected, but don’t affect the functionality that’s required for vdirsyncer.

Escaping hrefs

A weird quirk of WebDav is that it uses XML to encode requests and responses, but these XMLs include href elements which themselves are URL-encoded. These can turn into a pain if not dealt with properly.

Fortunately, since libdav encapsulates all the WebDav implementation, it makes it easy to enforce a clear API boundary. I’ve updated all functions in this library to clarify that all parameters and return values which include an href are not URL-encoded. This means that, outside of libdav, one never has to worry about whether an href is URL-encoded or not.

Internally, I’ve enforced a rule where an href is decoded as soon as it is parsed from the raw XML, and is encoded again only when actually serialising a request. This also makes it less confusing what’s going on internally.

Configuration changes

Last month I mentioned that I’ve been writing a parser to read the configuration format in the same syntax as the Python implementation of vdirsyncer. @untitaker provided me with some feedback on this and some insight on the existing format: the intent was to make the configuration format converge to toml and eventually make the configuration pure toml.

This really got me thinking that it is so close to toml that it might be a good moment to change the configuration format. This change would make migration a bit more work, but is also a good moment to lift some technical debt, add support for a few missing corner cases, and clear some ambiguity.

I’ve also been trying out himalaya, and its configuration syntax for credentials and alike is quite clear, so I want to draw some inspiration from it.

At this point, I’m rethinking the configuration as pure toml and taking a lot of notes on how the new format varies from the previous one. I intend to write a clear migration guide for people to switch without much hassle. I’ve considered the idea of writing a migration tool, but I don’t really know whether it makes sense yet or not (this will depend on the feedback from people when migrating over).

SPDX headers

I’ve followed a suggestion on behalf of the FSFE and added SPDX headers to source files to facilitate re-usability by others wanting to copy an entire file into a different project.

I’m not convinced that anyone actually wants to do this at this stage, but the effort isn’t much I don’t see any issues with this.

I considered using the reuse tool, which checks for this and other licensing details, but it seems to be highly opinionated and brings into scope other things which are not relevant to me.

— § —