Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

Interface for ipfs.files.cat (and alias ipfs.cat) #21

Merged
merged 1 commit into from
Jun 6, 2016
Merged

Conversation

nginnever
Copy link
Contributor

This is the beginning of the cat spec. Some notable issues I can think of:

  1. The test's aren't currently set up in npm package so I haven't tested the cat test file, but it is just a clone of the js-ipfs core test.
  2. Not sure about the promises return. I have to understand promises a bit better or where they are currently being used. js-ipfs-api cat isn't set up with promises and the js-ipfs cli isn't either to my knowledge. cc @dignifiedquire

@daviddias
Copy link
Contributor

  1. The test's aren't currently set up in npm package so I haven't tested the cat test file, but it is just a clone of the js-ipfs core test.

Couldn't you try them with npm link?

  1. Not sure about the promises return. I have to understand promises a bit better or where they are currently being used. js-ipfs-api cat isn't set up with promises and the js-ipfs cli isn't either to my knowledge. cc @dignifiedquire

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`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lowercase

@daviddias
Copy link
Contributor

- 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 }.
Copy link
Contributor

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."

Copy link
Contributor Author

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

Copy link
Contributor

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

@daviddias
Copy link
Contributor

Is all of that test-data required?

@@ -21,102 +22,94 @@ module.exports = (common) => {
common.teardown(done)
})

describe('.add', () => {
Copy link
Contributor Author

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

@nginnever
Copy link
Contributor Author

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.

{ path: 'data.txt',
    multihash: <Buffer 12 20 59 94 84 39 06 5f 29 61 9e f4 12 80 cb b9 32 be 52 c5 6d 99 c5 96 6b 65 e0 11 12 39 f0 98 bb ef>,
    size: 4,
    dataSize: 0 
}

While js-ipfs-api will expect JSON

{ Name: 'data.txt',
    Hash: 'QmVv4Wz46JaZJeH5PMV4LGbRiiMKEmszPYY3g6fjGnVXBS' 
}

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.

Error: Invalid ipfs ref path


### `cat`

> Streams the data contained by an IPFS object(s) at the given IPFS multihash..
Copy link
Contributor

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

Copy link
Contributor

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
Copy link
Contributor

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?

Copy link
Contributor Author

@nginnever nginnever May 27, 2016

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

ipfs-inactive/js-ipfs-http-client#280

@daviddias daviddias changed the title API proposal for ipfs.files.cat Interface for ipfs.files.cat (and alias ipfs.cat) Jun 6, 2016
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)
Copy link
Contributor

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

@dignifiedquire
Copy link
Contributor

lgtm woul just be nice to replace the b58 calls with multihashes

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants