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.