As I wanted to learn programming in rust, I just started working on a re-implementation of the rest-server in rust. I’ll call it rust-server 
and will put it to github once it’s finished.
3 Likes
I’m finished with the alpha version of
Although this is WIP it already worked pretty well for me…
I did not yet implement every feature that is implemented in rest-server, but I thought some additional ACL support might be nice.
So, rust-server allows to fine-tune user access; it allows to differentiate Read/Append/Modify access. With this feature you can define users that can only read (i.e. restore, mount, etc) the repo; users that can append (i.e. backup) to the repo and users that can modify (i.e. forget, prune) the repo.
Note, that this is an early alpha version and one of my first rust applications, feedback very welcome (best using github).
2 Likes
I moved your two posts above to their own thread, as they were a bit off topic in the original/previous one 
I hope you don’t mind (feel free to edit the topic by the way)!
While I understand that you did this because you were curious, which is great, I’m curious what your intentions are with this “copy” of rest-server? I’m honestly a bit worried that the community will end up with two copies of more or less the same thing, and that this will split up development resources and also need more support if people use the Rust version and issues cannot be investigated within the same context as the rest of the restic ecosystem (being Go code).
It’s not that I mind other software, not at all, I just am not sure what will come out of this. I don’t think there’s anything to worry about, mostly just thinking out loud.
1 Like
Honestly, my intentions were simply to learn rust and get a feeling about the differences between Go and Rust. And IMO the best thing to learn something is to repeat some work.
Well, this is what happens in free/open source software and I think this is what it lives from 
If rust-server is of any value for some users, it might get supported and people will be found to continue working on it. If not, that’s fine too!
Moreover I like a lot to work in my free time without the necessity to always think about being economic - this is what we all do in our professions, no?
About development resources for restic: Franky, seeing the constantly open number of PRs, the bottleneck here is obviously not the development resources, but the number of maintainers. But again, this is a project of people working on it in their free time, so no need to think too economical…
2 Likes
Always great to do it that way so one can really compare. Speaking of that, did you do like a 1:1 rewrite so the code bases can be compared in detail, or did you change any of what it does and so on such that it’s not entirely comparable anymore?
Yep, it’s not about economics.
1 Like
I did not rewrite the code base, but instead I implemented the specification of the REST backend.
And I had a look at the options on the rest-server CLI and tried to implement most (basically only --max-size and --prometheus still missing).
Moreover, the storage layout it uses is identical to the restic on-disc layout (as it is with rest-server), so it can be used as a 100% replacement of rest-server.
I’ll dig a bit into the comparison between both implementations and post my conclusions…
2 Likes