<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Status-Update on WhyNotHugo</title><link>https://whynothugo.nl/tags/status-update/</link><description>Recent content in Status-Update 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/status-update/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>Nine months of Xendmail</title><link>https://whynothugo.nl/journal/2024/01/16/nine-months-of-xendmail/</link><pubDate>Tue, 16 Jan 2024 11:27:11 +0100</pubDate><guid>https://whynothugo.nl/journal/2024/01/16/nine-months-of-xendmail/</guid><description>Last year I wrote xendmail, a tool based on the proposal mentioned in my thoughts on sendmail in 2023 article. Xendmail exposes the same interface as sendmail1, it takes an email as input, reads credentials from the user&amp;rsquo;s secret store, and dispatches the email via an the appropriate SMTP server. Xendmail implements the 5% of sendmail that I need, plus 5% extra which no other implementation offers.
The approach has somewhat worked, but has some issues.</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>vdirsyncer status update, May 2023</title><link>https://whynothugo.nl/journal/2023/05/27/vdirsyncer-status-update-may-2023/</link><pubDate>Sat, 27 May 2023 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2023/05/27/vdirsyncer-status-update-may-2023/</guid><description>So far, libdav seems to be working pretty solid for interacting with CalDav server, and davcli has been handy for interactively inspecting remote collections.
There are a few reported issues for the previous vdirsyncer implementation that are related URL decoding. These can probably be inspected well with davcli, but I still need to write a proper guide that people can follow to do this. I want to use this to confirm that the new implementation handles all these scenarios fine (and debug them if necessary).</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>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>Shotman 0.2 development update part 2</title><link>https://whynothugo.nl/journal/2022/10/04/shotman-0.2-development-update-part-2/</link><pubDate>Tue, 04 Oct 2022 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2022/10/04/shotman-0.2-development-update-part-2/</guid><description>After the initial proof of concept of the shotman rewrite, my next goal was to have an implementation that could fully replace the previous version for daily usage.
My main use of shotman is &amp;ldquo;take screenshot of current window&amp;rdquo;, and I have two other (less frequent) use cases. They are all mapped to global hotkeys:
Super+p to screenshot the current window. Super+Shift+p to screenshot a region. Super+Ctrl+p to screenshot the entire output.</description></item><item><title>Shotman 0.2 development update part 1</title><link>https://whynothugo.nl/journal/2022/08/28/shotman-0.2-development-update-part-1/</link><pubDate>Sun, 28 Aug 2022 00:00:00 +0000</pubDate><guid>https://whynothugo.nl/journal/2022/08/28/shotman-0.2-development-update-part-1/</guid><description>Update: This article was renamed to &amp;ldquo;part 1&amp;rdquo; when publishing part 2.
These last couple of week I&amp;rsquo;ve been putting a lot of time into shotman. Shotman is a small GUI tool I wrote a few months ago. It shows a small preview window when a screenshot is saved, and has controls to copy the screenshot into clipboard or delete it right away.
The previous version was 0.1. This newly written version is to be 0.</description></item></channel></rss>