Future of vdirsyncer

[WhyNotHugo]

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.

[duckunix]

I think I agree with you. One reasons why I switched my primary distro is that some apps I have become dependent on and are written in python started to get stale.

Golang has many advantages (whole compiled vs. interpreter, ease of distribution, cross platform, etc) with as far as I know few downsides aside from learning a new language.

If the move makes it easier for people to help support this project, I am all for it!

And thank you for writing this and thinking about its future!

[dilyanpalauzov]

I appreciate very much that this project is maintained. The decision of changing the implementation language is up to the person, who maintains the code.

Perhaps a gradual transition approach, where some parts are changed to use another language, other parts are in Python, will work best, as it was with Rust. The discussion Rust/Go is biased.

My wish is, that the WebDAV protocols are very well supported and e.g. the Collection Synchronization for WebDAV does work.

[WhyNotHugo]

The discussion Rust/Go is biased.

I agree. I really like Rust TBH, but I feel it'd take a lot more time to write this in Rust, and it's a high barrier for contributions, but the result in Rust would likely be more solid too.

Perhaps a gradual transition approach, where some parts are changed to use another language, other parts are in Python, will work best, as it was with Rust.

Yup, I'm still trying to figure out the plan around this. Python modules with Rust code are not uncommon, which gives Rust a much clearer transition path. FWIW, this has been tried before, but maybe it was too early in the ecosystem.

[WhyNotHugo]

Currently not much going on on this front. golang currently has some limitations to the its timezone library which is blocking parsing timezones from icalendars correctly.

See emersion/go-ical#10.

[dilyanpalauzov]

I cannot help. The non plus ultra library for dealing with iCalendar files is libical, written in C. It has bindings for some languages, including GObject. It should exist some software integrating GObject with Go.

[Wastus]

I've used it just now and I used the docker image provided by Bleala. It worked easily enough for me to get my contacts and calenders moved from my server to a VM which I'm testing my new server setup on.

I'm really grateful this tool exists. Sure, docker might not be the most efficient way to run this, but it has the benefit, that you can ship the python version you need for it to work, independently of what Debian stable is shipping.

There aren't many tools out there doing this - I found https://git.cloudron.io/cloudron/cloudron-davsync, but that uses a heavily outdated DAV library (depends on version 1.x where 4.x is available), so I didn't trust it. It's a Node.JS app, not sure how well that library handles all the WebDAV stuff.

Just a bit of input from a (as of yet) one time user.

[WhyNotHugo]

Glad to hear it worked for you! The docker image is actually quite suitable for one-time usages (and not terrible for desktop TBH).

[WhyNotHugo]

I've recently posted on the topic of the re-write. For now I just have some very rough code for filesystem storeges. I'm focusing on making sure the storage API is async and non-blocking, so later I won't have to deal with that aspect of the API when writing the networked storages. Not sure if I'll go with CalDav or EteSync next.

I've recently switched to using tasks.org on Android (LineageOS), and have been noticing some DAV features it uses that are not implemented on vdirsyncer -- so I'm keeping the "allow syncing other metadata" idea well in mind.

[Thaodan]

Doesn't the switch to Golang move the problem around? Golang has the downsides of bundling everything.
Plus the tendency to insist on language purity (either it works with a go library or it has to be reimplemented in Go).

From what I read Debian is at fault for not keeping up with Python, it is not the first time that Debian has libraries that are to old.

I think in the long run moving to go might help but in terms of getting contribution it only help for those that want to contribute in Go.
In the short run it will be worse.

[Thaodan]

Perhaps a gradual transition approach, where some parts are changed to use another language, other parts are in Python, will work best, as it was with Rust.

Yup, I'm still trying to figure out the plan around this. Python modules with Rust code are not uncommon, which gives Rust a much clearer transition path. FWIW, this has been tried before, but maybe it was too early in the ecosystem.

The python-cryptography package might be a good example for such a case.

[3lpsy]

I can't seem to find the repo/branch for the rewrite. Is it still private? I may be interested in working on it.

[d7415]

I can't seem to find the repo/branch for the rewrite. Is it still private? I may be interested in working on it.

I think this is it https://git.sr.ht/~whynothugo/vdirsyncer-rs

I don't think it's mirrored to GitHub, at least not yet.

[WhyNotHugo]

I think this is it https://git.sr.ht/~whynothugo/vdirsyncer-rs

Yup, that's right. It's in early stages right now. I've mostly defined a clean API/abstraction for storages, and I'm currently working on the caldav client.

The code there doesn't really do much though, but you're welcome to look through it.

I'll try and publish a status update on what's going on soon. I have secured funding for the time being so have been working on this quite intensively the last few weeks and hope to have some of the early milestone in the coming weeks/months. I'm really focusing on making all the underlying bits reusable crates so that other related projects can leverage these too.

[ghost]

Why not just C++? On mobile it can be run as a termux application, and even without termux, it is quite possible to compile console programs with bionic.

[WhyNotHugo]

Why not just C++?

Mostly because I don't know C++ but do know Rust.

On mobile it can be run as a termux application, and even without termux, it is quite possible to compile console programs with bionic.

Rust builds fine in LinuxMobile, Android and even iOS. The rewrite has a strong split between the actual logic (which is a library) and the frontend/cli, so it should also be usable for graphical applications on those environments.