-
Notifications
You must be signed in to change notification settings - Fork 124
Interface for ipfs.files.cat
(and alias ipfs.cat
)
#21
Conversation
Couldn't you try them with npm link?
Every js-ipfs-api call has a promise API since last October/November. However, the previous set up doesn't work for how we now have to implement this cross compatible methods, but we do have a way to achieve that, which can be observed in the already implemented Object API - https://github.com/ipfs/js-ipfs-api/blob/master/src/api/object.js |
@@ -55,6 +55,29 @@ test.all(common) | |||
|
|||
A valid (read: that follows this interface) IPFS core implementation, must expose the following API. | |||
|
|||
## Files | |||
|
|||
### `Cat` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lowercase
cat'ing a big file is important https://github.com/ipfs/js-ipfs-api/blob/master/test/api/cat.spec.js#L43-L58 |
- Buffer, the raw Buffer of the multihash (or of and encoded version) | ||
- String, the toString version of the multihash (or of an encoded version) | ||
|
||
`callback` must follow `function (err, stream) {}` signature, where `err` is an error if the operation was not successful and `stream` is a readable stream in object mode that contains objects representing a file in the form of { path: fileName, stream: fileData }. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In cat there is no filename, just the stream of the content.
"stream
is a readable stream of the content referenced by the multihash."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The core is returning a readable object stream from the exporter, which will send one object containing { path: (the multihash provided to cat), stream: (a readable stream provided for that file) }
Should I PR a change to the js-ipfs core here https://github.com/ipfs/js-ipfs/blob/master/src/core/ipfs/files.js#L48
to this
const exportStream = Exporter(hash, self._dagS)
exportStream.on('data', (file) => {
callback(null, file.stream)
})
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep. The path
on cat is irrelevant, even misleading
Is all of that |
@@ -21,102 +22,94 @@ module.exports = (common) => { | |||
common.teardown(done) | |||
}) | |||
|
|||
describe('.add', () => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this fails on js-ipfs-api
TypeError: Invalid non-string/buffer chunk
eb03ac5
to
72018dc
Compare
Having trouble writing tests that will work with both js-ipfs core and js-ipfs-api since the requirements vary between the two. Conversation on how to respond from the add function in js-ipfs core here concluded with keeping dagnode objects as the return type for core.
While js-ipfs-api will expect JSON
Cat also can take both buffer and string forms of multihash for input in js-ipfs core, but in js-ipfs-api only string is supported.
|
|
||
### `cat` | ||
|
||
> Streams the data contained by an IPFS object(s) at the given IPFS multihash.. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is "object" accurate? Getting a stream of data from an ipfs object is object.get
's job, right? These are "files"?
@diasdavid terminology help please
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are thinking right, @noffle. Object is a DAGNode, cat returns a File
}) | ||
}) | ||
|
||
// This fails on js-ipfs-api |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? Is there a PR with a fix?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's an old comment from before i made this pr to upgrade the js-ipfs-api to accept buffer inputs Will remove :)
4c337c2
to
bc04eba
Compare
ipfs.files.cat
(and alias ipfs.cat
)
expect(res[0].path).to.equal('data.txt') | ||
expect(res[0].node.size()).to.equal(17) | ||
const mh = 'QmVv4Wz46JaZJeH5PMV4LGbRiiMKEmszPYY3g6fjGnVXBS' | ||
expect(bs58.encode(res[0].node.multihash()).toString()).to.equal(mh) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
using multihashes would be much nicer
lgtm woul just be nice to replace the b58 calls with multihashes |
This is the beginning of the cat spec. Some notable issues I can think of:
cat
isn't set up with promises and the js-ipfs cli isn't either to my knowledge. cc @dignifiedquire