libgopar

[brenthuisman]

The second thing I'd like to do is make gopar suitable for use as a library. By that I don't mean all the primitives it contains, but (also?) the interface through main(). The fastest way to to it would be to turn main() into par(args []string), and have main() call it. However I'm certain you would prefer a break up into separate create(), verify() and repair() functions :) In which case, the flagsetting part of main needs to be duplicated. Copy paste or is there a cleaner way? With my C++/Python hat on, I think of hiding all that in a class, but that doesn't seem to be the Go way so I ask.

• What form would you prefer? Maybe another?
• Where in the file hierarchy would you put the lib, meant for external use? Is there a convention like /cmd? Maybe just the root?

[akalin]

Yeah, I'm open to this, but first I'd like to ask what the use case of this would be. Is the intent to replicate the command-line app exactly in some other form? If so, then a single par(args []string) function might actually be best, but I think that's not what library integrations look like most of the time.

I'd imagine if it were to integrate it in some other app, then each high-level function (create, verify, repair, etc.) would be a single function in a package, and all the flags would be replaced with Options structs.

On the other hand, if the par stuff is meant to be one command in a bigger command-line app (like how create etc. are all different commands in the single par app), then I think then the interface for that can be a single function.

So yeah, it all depends on what you ultimately want to do. :)

[brenthuisman]

I forked libpar2cmdline and added a main(args []string) style function as interface because it was such a pile of spaghetti and, similar to gopar, there's a bit of initialization going on before the actual c/v/r functions are called which I didn't want to replicate. It works perfectly (of course), and ultimately that's what I care about, but having three functions would be a bit cleaner, where you pass in a filename (/handle?) and a set of parameters (The Options struct would be a struct of all options with a default set?).

I imagine you'd like to support not just my application, hence the question :)

[akalin]

Yeah, having separate functions for the major operations would be the way I'd do it, I think. For example, Create would look like (CreateResult, err) Create(parFile string, inputFiles []string, options CreateOptions, delegate ...);, where CreateOptions would look something like struct { blockSize int; recoveryBlockCount int; ... }, CreateResult would maybe have some info about the created files, and delegate would be called to log events and such.