libgopar about gopar HOT 3 OPEN

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. :)

from gopar.

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 :)

from gopar.

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.

from gopar.