wishlist: git backend

[chrysn]

For distributing calendar and address book content outside of the WebDAV context, as well as for archival, versioned backup and to debug what happened when suddenly every other contact's picture is getting blurry, I find it useful to store WebDAV content in a as files in a git repository. (Also, that's what my family PIM data has been stored in for more than a decade, even while my tooling changed from dav2git (whatever my server was back then) to radicale, calypso, and back to radicale).

Compared to the copy keeping approach of dav2git, running this directly in the DAV server has the advantage that it can produce good commit messages; not only does it set a proper author (well at least username <username@webdav>) that one can blame, but it can also put a User-Agent line in the commit message, and an X-Client and Origin when web tools such as CalDavZAP are used -- plus it can look into the files to at least give a "Modify {name of event} ({date of event})" or "Add {contact name}" (but that's something a dav2git style replication could do too).

The rustical_store module and the DataStoreConfig look flexible enough already to add a backend.

I'd love to write such a backend, but am currently short of time -- so I'm documenting here that I think it'd be a good idea to have it, maybe someone is interested to pick it up, or at least it can gather feedback until I might start on it.

[lennart-k]

I get that it might bring some peace of mind to have the calendar organized in the file system and to basically get versioning more or less for free with git. Especially since that feels the least attached to any specific calendar server. But I'm also not too keen on having a file system-based data store.

What I could imagine is adding a small task that would automatically export the calendars to the file system so one could back them up in a portable format.
This can otherwise already be done through the frontend.

Having some kind of audit log is also something I have in mind and if I find the time I might implement that.

The reason however why I'd like to stick with the SQL database is that (aside from the simplicity of SQL statements) I can wrap multiple changes into transactions and expose a set of well-defined operations.
The idea is to do all the validation before saving new data and to thus catch errors before we end up in a corrupted state.
If we expose a file system users might be more inclined to do edit the files directly and by accident break things (e.g. by specifying a wrong timezone id). I would also always have to watch out that the file system and the index are in sync.

So I think the route I would go would rather be to keep an SQL database with a restrictive but correct interface and then offer automatic export to the file system as a feature.

You can of course still give it a shot but at the moment I'll probably not merge any new storage backends since my main priority is to get everything rock-solid and offer a simple out-of-the-box experience such that I can blindly recommend this project to others with a good conscience.