<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Vdirsyncer on WhyNotHugo</title><link>https://whynothugo.nl/tags/vdirsyncer/</link><description>Recent content in Vdirsyncer on WhyNotHugo</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Sat, 30 Mar 2024 21:33:22 +0100</lastBuildDate><atom:link href="https://whynothugo.nl/tags/vdirsyncer/posts.xml" rel="self" type="application/rss+xml"/><item><title>Vdirsyncer status update, March 2024</title><link>https://whynothugo.nl/journal/2024/03/29/vdirsyncer-status-update-march-2024/</link><pubDate>Fri, 29 Mar 2024 15:11:00 +0100</pubDate><guid>https://whynothugo.nl/journal/2024/03/29/vdirsyncer-status-update-march-2024/</guid><description>Sync status[permalink] As I mentioned before, when synchronising two storages, the sync algorithm keeps around a local &amp;ldquo;status&amp;rdquo; with some basic metadata. Future executions use this metadata to understand which side has changed and which side needs updating.
I had to re-write most of my previous status implementation due to the issues that I mentioned in my previous status update. The new implementation keeps track of the metadata for the latest synchronised version, instead of the latest seen version.</description></item><item><title>vdirsyncer: rewriting status management</title><link>https://whynothugo.nl/journal/2024/01/27/vdirsyncer-rewriting-status-management/</link><pubDate>Sat, 27 Jan 2024 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2024/01/27/vdirsyncer-rewriting-status-management/</guid><description>Current state[permalink] Vdirsyncer keeps a &amp;ldquo;status&amp;rdquo; file locally. The status file contains metadata from items on both storages the last time they were synchronised. My current implementation runs the synchronisation process, and then returns a new status, which should be saved to disk until next time.
I decided on this API since it made the whole codebase easier to reuse in different scenarios, including situation where the local system has no persistent storage (and the status could be saved onto a storage server, or wherever feasible).</description></item><item><title>vdirsyncer: preparing for alpha version</title><link>https://whynothugo.nl/journal/2023/12/21/vdirsyncer-preparing-for-alpha-version/</link><pubDate>Thu, 21 Dec 2023 18:30:23 +0100</pubDate><guid>https://whynothugo.nl/journal/2023/12/21/vdirsyncer-preparing-for-alpha-version/</guid><description>I&amp;rsquo;ve been synchronising my calendars with the still-experimental rewrite of vdirsyncer lately. vdirsyncer --sync --daemon has been running for about three days now. The --daemon flag makes it run continuously, synchronising changes every five minutes.
Eventually I want --daemon to monitor for changes and immediately synchronise when changes occur. Until monitoring of storages is actually implemented, it simply syncs every five minutes.
This solves a long standing issue in vdirsyncer: there&amp;rsquo;s no way to continuously sync in background.</description></item><item><title>vdirsyncer status update, November 2023</title><link>https://whynothugo.nl/journal/2023/11/27/vdirsyncer-status-update-november-2023/</link><pubDate>Mon, 27 Nov 2023 19:51:45 +0800</pubDate><guid>https://whynothugo.nl/journal/2023/11/27/vdirsyncer-status-update-november-2023/</guid><description>Designing the low level icalendar parser took longer than it should have taken. To be sincere, part of the problem was my trying to be too ambitious in its scope and growing beyond the strictly necessary requirements.
Requirements[permalink] The main goal of this parser (now called vparser) is to parse only the basic structure of icalendar and vcard files. The main requirements for vdirsyncer&amp;rsquo;s use case are:
Extracting the UID from an entry (calendar component or vcard).</description></item><item><title>vdirsyncer status update, October 2023</title><link>https://whynothugo.nl/journal/2023/11/01/vdirsyncer-status-update-october-2023/</link><pubDate>Wed, 01 Nov 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/11/01/vdirsyncer-status-update-october-2023/</guid><description>After having an initial version of the configuration parser, I&amp;rsquo;ve moved on to working on the actual command line for vdirsyncer itself.
Replacing Box&amp;lt;dyn Storage&amp;gt; with Arc&amp;lt;dyn Storage&amp;gt;[permalink] This section is pretty technical and requires some understanding of Rust.
In my synchronisation algorithm, the type representing the pair to be synchronised, SyncPair kept references to the Storage instances, and these shared references had started to become a pain point due to Rust&amp;rsquo;s lifetime rules.</description></item><item><title>A configuration format for vdirsyncer v2</title><link>https://whynothugo.nl/journal/2023/10/05/a-configuration-format-for-vdirsyncer-v2/</link><pubDate>Thu, 05 Oct 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/10/05/a-configuration-format-for-vdirsyncer-v2/</guid><description>Settling down a configuration format for the upcoming vdirsyncer v2 has taken more than I anticipated. These is a summary of my journey, considerations and the current state.
The previous format[permalink] My first approach was to retain the existing configuration format. I&amp;rsquo;ll call this one the &amp;ldquo;legacy&amp;rdquo; format, to keep language simple. I wrote a parser for it but it was far from trivial and, honestly, extremely complicated code. The configuration format itself is a bespoke format designed for vdirsyncer.</description></item><item><title>vdirsyncer status update, August 2023</title><link>https://whynothugo.nl/journal/2023/08/26/vdirsyncer-status-update-august-2023/</link><pubDate>Sat, 26 Aug 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/08/26/vdirsyncer-status-update-august-2023/</guid><description>I had family visiting during this past month, so I&amp;rsquo;ve taken some time off to spend with them. Progress has therefore been slower than usual.
Sub-tasks missing from planning[permalink] As I mentioned a few months ago, the NLnet foundation is currently funding my work rewriting on vdirsyncer. As part of this process, I&amp;rsquo;ve shared a full plan with tasks that need to be done and an estimation for them.
While I had a pretty solid plan on how to approach re-writing vdirsyncer, some requirements did fly under my radar.</description></item><item><title>vdirsyncer status update, July 2023</title><link>https://whynothugo.nl/journal/2023/07/17/vdirsyncer-status-update-july-2023/</link><pubDate>Mon, 17 Jul 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/07/17/vdirsyncer-status-update-july-2023/</guid><description>CardDav support[permalink] This month I&amp;rsquo;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&amp;rsquo;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.</description></item><item><title>vdirsyncer status update, June 2023</title><link>https://whynothugo.nl/journal/2023/06/30/vdirsyncer-status-update-june-2023/</link><pubDate>Fri, 30 Jun 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/06/30/vdirsyncer-status-update-june-2023/</guid><description>This month started out rather slow, with me taking a week off on vacation and then coming back home only to be sick in bed for another week. But it ended up being rather productive after all.
Configuration parsing[permalink] My initial goal since last month was to implement a small binary that can work as a drop-in replacement for vdirsyncer. With some basic sync scenarios working1, the next step was to parse the configuration file.</description></item><item><title>Introducing davcli</title><link>https://whynothugo.nl/journal/2023/05/01/introducing-davcli/</link><pubDate>Mon, 01 May 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/05/01/introducing-davcli/</guid><description>I mentioned in the past that libdav (the library which I&amp;rsquo;ve written to interact with caldav and carddav servers) implements DNS-based discovery.
This should make any tools built on this library a lot easier to configure for end users. One such tool so far is davcli, a simple command line tool to interact with caldav servers manually or via simple scripts. It is also useful for hosting providers that want to validate that discovery is set up correctly.</description></item><item><title>DNS-based discovery for CalDav and CardDav</title><link>https://whynothugo.nl/journal/2023/04/30/dns-based-discovery-for-caldav-and-carddav/</link><pubDate>Sun, 30 Apr 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/04/30/dns-based-discovery-for-caldav-and-carddav/</guid><description>rfc6764 describes a mechanism for caldav service providers to expose exactly where their server is located while requiring minimal input from the user.
The main intent here is that if you are hosting your email and calendar for example.com, your users only need to provide their calendar application with the domain example.com and it can automatically figure out exactly where the caldav server is located. Let&amp;rsquo;s assume, for this example, that the caldav service is located at https://dav.</description></item><item><title>libdav live test results</title><link>https://whynothugo.nl/journal/2023/04/27/libdav-live-test-results/</link><pubDate>Thu, 27 Apr 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/04/27/libdav-live-test-results/</guid><description>One of my goals for re-writing vdirsyncer was to write &amp;ldquo;live tests&amp;rdquo;. These tests are series of operations against a real CalDav server, failing if the server doesn&amp;rsquo;t behave as expected (or if it doesn&amp;rsquo;t support a specific feature).
I&amp;rsquo;ve had this working for a couple of weeks now, and while it always feels like &amp;ldquo;it could be better&amp;rdquo; (the code quality isn&amp;rsquo;t great, but it&amp;rsquo;s also not my worst), the reality is that it fulfils its goal and can be improved later as needed.</description></item><item><title>vdirsyncer status update 2023-03</title><link>https://whynothugo.nl/journal/2023/03/28/vdirsyncer-status-update-2023-03/</link><pubDate>Tue, 28 Mar 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/03/28/vdirsyncer-status-update-2023-03/</guid><description>This is a long overdue update on the status on vdirsyncer&amp;rsquo;s rewrite. I keep thinking &amp;ldquo;I&amp;rsquo;ll just finish this one bit before publishing it&amp;rdquo;, but that always seems to be a day or two in the future, so here goes.
Funding[permalink] I&amp;rsquo;m very happy to announce that the NLnet foundation has agreed to fund my work on vdirsyncer. Thanks to this, I&amp;rsquo;ve been able to put a lot more focus hours into this project, which would have not been possible without this support.</description></item><item><title>vdirsyncer: looking for hosted Dav servers</title><link>https://whynothugo.nl/journal/2023/01/30/vdirsyncer-looking-for-hosted-dav-servers/</link><pubDate>Mon, 30 Jan 2023 15:48:50 +0100</pubDate><guid>https://whynothugo.nl/journal/2023/01/30/vdirsyncer-looking-for-hosted-dav-servers/</guid><description>Current state of affairs[permalink] As part of vdirsyncer&amp;rsquo;s test suite, I currently run tests against a multiple CalDav/CardDav servers. The CI pipeline does this by downloading dockerised versions of all the servers, starting them up and then running tests.
This isn&amp;rsquo;t ideal. On CI, the radicale, xandikos and baikal containers get downloaded on each test run which really doesn&amp;rsquo;t scale1. Adding more and more servers will just make the whole test suite slower, as well as more maintenance work.</description></item><item><title>A vdirsyncer rewrite</title><link>https://whynothugo.nl/journal/2022/04/18/a-vdirsyncer-rewrite/</link><pubDate>Mon, 18 Apr 2022 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2022/04/18/a-vdirsyncer-rewrite/</guid><description>I&amp;rsquo;ve been planning a full rewrite of vdirsyncer for quite some time now. So far work on vdirsyncer (both on the original version and on this rewrite) has happened during free time and is mostly unpaid. My intention is to seek sponsors for this rewrite, so that I can dedicate more hours to this project and deliver a well polished product to the open source ecosystem.
By becoming a sponsor, you will allow me to focus on this endeavour and spend much more time on it than I ever could on &amp;ldquo;another side project&amp;rdquo;.</description></item></channel></rss>