href: #1136

Since the pin callback has been removed, the current AddFile doesn't do pinning yet.
This doesn't affect ipfs add since it does explicit PinRoot() afterward.

One approach is to define AddFileMaybePin.

This looks pretty good to me. My only concern is making sure that things that are commands lib specific stay in the commands lib, for example the Object struct and the progress reader stuff feels a bit out of place outside of the commands lib.

In the beginning I'd have opted the progress reader to be in commands lib, but the reader has to wrap the file before the params.Add in L286.

One option is to add generic callback func option.
Similarly for outputDagnode (the reason why the Object struct is pulled into coreunix in the first place), if this is to be turned into a callback func.

In this case, progressReader can be kept out of coreunix if an interface ProgressReaderFile is defined in commands/file.

In this case, progressReader can be kept out of coreunix if an interface ProgressReaderFile is defined in commands/file.

Hrm... youre right. that seems a bit more complicated.. in that case its probably fine to leave things where they are now.

@whyrusleeping fixed. Also progressReader depends on AddedObject for the output object so if it is moved to commands/files, then it needs to import coreunix and use coreunix.AddedObject. Messier.

yeah... i'm all for being less messy.

Assign to me when i should CR -> merge

@jbenet the PR works. It needs CR for the design aspect.

sorry for the delay will try to get to this this week, else early next.

this roughly LGTM. thoughts @whyrusleeping ?

Yeah, i think this looks good.

ok. rerunning tests as they failed.