Compute a restore proc from a backup proc string

[Roman2K]

Suggestion by @lavalamp originally posted in the defunct GitLab repo (old issue)

I realize there's no way to know the inverse of a user-specified command, but it would be pretty handy to at least know where I ought to plug it in :)

[Roman2K]

My response:

Actually, automatically computing the reverse chain is what I had in mind originally 🙈 But as I added new procs, I realized there were too many discrepancies from one to the other to to be able to easily compose a reverse chain from the reverse version of each proc (unproc) because there can exist differences between proc and unproc, such as:

• different arguments (ex: index takes a path, uindex no)
• different requirements (ex: uparity requires checksum + group, parity no)
• and most blocking... the requirements of a proc may come from different sources, forcing to make assumptions as to which proc to use to meet the requirements (ex: checksum for uparity -> can come from uindex or checksum)

Instead of introducing potential brittleness, I felt I would be more confident in the restore process if the restore script was written just as explicitly as the backup script.

it would be pretty handy to at least know where I ought to plug it in :)

If you were to start working on such a feature, I suggest you start from listing the types returned by ArgLambdas in argproc (the proc string parser). And for each, implement an unprocer interface (defines Unproc() (Proc, error)) that returns the reverse Proc. You would implement it in procs.Chain too, which would return the unproc of the procs composing it, in reverse order. All of them must implement Unprocer, otherwise return an error. This way, reversing a chain containing chains works too. But then you have to check the requirements are met. So each proc would define a list of what they do (assign checksum, group chunks, etc.) and it becomes... a tangled mess... At least I don't yet have a clear vision of how to do it in a maintainable manner 😅