Description
Rationale
This issue comes out of the discussion surrounding #5611. As more and more ipfs commands support some form of streaming response, go-ipfs-cmd encoders are likely to get called more than once, and chaining together correctly, particularly in the case of a text encoder, may require some kind of knowledge about what was sent last.
In the LS case, we need to know, when LS-ing multiple directories, whether the latest directory entry/entries streamed is in the same directory as the last entry streamed, so we can insert a directory hash and possibly column headings before we start with a new directory. We've solved this for now by simply sending the Hash of the directory streamed last as an extra field in all streamed entries. This seems less than ideal, since it's really a client level concern.
Possible Solutions
- Force streaming commands to provide solutions on a case by case basis like the current implementation of
ls - Have all cases where this is needed use a PostRun instead of an encoder (does generally break web requests with
encoding=text-- see Add command does not support json encoding #1121 for an example) - Allow an encoder to see the "last streamed value" -- in the case of
lsthis is all that's needed and could simply be an extra parameter in the function passed to MakeTypedEncoder. - Allow an encoder to pass arbitrary state along between calls to an encoder. This might be done by adding a return value to the encoder function (in addition to the error) and perhaps adding a StateType field to a the command. The seems harder to implement but perhaps while just passing the last value to
lsis enough other commands might need to pass different types of state between calls.