docs: add mfs stream ls methods #401
Conversation
ghost
assigned
Implementation of ipfs-inactive/interface-js-ipfs-core#401 License: MIT Signed-off-by: achingbrain <[email protected]>
Implementation of ipfs-inactive/interface-js-ipfs-core#401 License: MIT Signed-off-by: achingbrain <[email protected]>
alanshaw
left a comment
alanshaw
left a comment
There was a problem hiding this comment.
Given that these are new APIs, do you think should they return cid (CID instance) in the response objects instead of hash (a string encoded CID)? Towards #394 and if we're serious about doing that then it would save us a breaking change down the line.
Do you think it would be confusing for developers if the objects returned from files.ls and files.ls*Stream are different shapes? I think yes, it probably is, but I could be persuaded.
@hugomrdias @daviddias do you have any strong opinions?
|
imo they should return the same as |
|
I'm with @hugomrdias and @alanshaw |
|
It think it's better for them to be consistent with the existing APIs, then we can break them all in one go down the line. |
|
Can we get some tests in here? Can we support it in |
The only mfs ls method at the moment buffers the output into an array before returning it to the user. This PR adds two new methods, lsPullStream and lsReadableStream to allow the user to either buffer the output themseleves (in case they need sorting, etc) or just stream it on to an output of some sort. N.b the http API will not actually do any streaming until ipfs/kubo#5611 is released.
achingbrain
force-pushed
the
add-ls-streams
branch
from
0ca1539 to
e2dfe3b
Compare
|
Tests are added. ipfs-inactive/js-ipfs-http-client#903 is the other part of this. |
The only
mfs.lsmethod at the moment buffers the output into an array before returning it to the user. This PR adds two new methods,lsPullStreamandlsReadableStreamto allow the user to either buffer the output themselves (in case they need sorting, etc) or just stream it on to an output of some sort.