Future of vdirsyncer

I've been thinking about the general direction of vdirsyncer for a few weeks now (or is it actually months already?).

Python has proven to be a bad choice for maintaining this project long term. Debian has such an old version it's hard to write modern Python that works on it. Meanwhile, other distros keep up to date with upstream's latest. Improvements on Python are hard to pick up (I can basically use python 3.10 improvements in a few years, when it's the oldest version we support, so, not anytime soon).

Plus, each time a library is added, it produces a burden on distribution packager on packaging yet another library.

I'm very tempted to port vdirsyncer to golang. Rust is nice and all, but it's a far too high bar for contributions, and its ecosystem isn't very mature when it comes to webdav/icalendar/vcard/etc. Golang has good libraries, is very very fast, and is very easy to ship. It's high-level enough that writing it and maintaining it won't be a nightmare too.

I'd still encourage distributions to package it, but for those that don't, access is easier. Testing also becomes a lot simpler, and it's a good opportunity to re-think things. I'd personally like something that can be triggered when a collection is altered, and run at that point (probably with a small delay, the finer details are to be seen).

That would result in very fast push of changes. Pulling could be done on a schedule via cron(8) or a systemd.timer(5).

Go libraries in the ecosystem exist, and many of them are being actively maintained, so I think this is a better opportunity for mutual collaboration.

I'll probably only maintain the Python version until that new project has a working release -- I rely on vdirsyncer myself, so always need a working version.

The issue does not name implementation files, tests, or entry points. First review the existing vdirsyncer architecture and the comment discussion, then assess the proposed Go port and event-triggered push design. Done would require an agreed direction and a working replacement release, not a single contained change.