> thanks! git-remote-gcrypt has rclone support, which provides all possible backends.
Oh that's awesome, I didn't catch the rclone support while skimming the README. rclone is such an excellent piece of software.
> the addition here is a second object store with compare-and-swap semantics making it possible for multiple writers to collaborate safely.
I think I must have misunderstood this point too -- the compare and swap semantics that you want are against dynamodb, right with raw/"dumb" storage on S3?
If I could request one thing it would be some extra interface files with "drivers" for the two concerns which are currently being handled by main.go... The locking mechanism and the raw storage mechanism.
Distilling the interface to these components would make it so easy for someone to come along and implement replacements! For example, one might like to see SQLite, FoundationDB, etc as metadata/synchronization drivers.
If there's a clear interface then it's easy to say "sure, send a commit with the implementation and we'll consider including it!", and leave implementation up to people who want the feature.
> many infra providers have object storage with those semantics, my preference is aws.
Yeah I bet this would work out of the box against other infra providers as well? S3 has basically become the defacto API everyone chases anyway.
the addition here is a second object store with compare-and-swap semantics making it possible for multiple writers to collaborate safely.
many infra providers have object storage with those semantics, my preference is aws.