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

dag api: add {ls, tree} #121

Closed
jbenet opened this issue Mar 9, 2017 · 7 comments · Fixed by ipld/js-ipld#191
Closed

dag api: add {ls, tree} #121

jbenet opened this issue Mar 9, 2017 · 7 comments · Fixed by ipld/js-ipld#191

Comments

@jbenet
Copy link

jbenet commented Mar 9, 2017

We should add the following commands to the core/dag interface:

  • ipfs.dag.ls(path) - show the first level link names of the node pointed at by <path>
    • include simple return value one, for small dag objects
    • include stream/iterator based one, for huge dag objects
  • ipfs.dag.tree(path) - enumerate all entries in the graph, parting from node at <path>.
    • include simple return value one, for small subgraphs
    • stream/iterator based so that we can explore massive graphs with it.

cc @diasdavid @whyrusleeping

@jbenet
Copy link
Author

jbenet commented Mar 9, 2017

the ipld explorers will get worked on next week. would be great to have this in before that work starts. https://hackmd.io/EYVgHApgTDAsC0BDRIDG9bCgRia2E8EiqAbAAymqojkDMiQA

@jbenet
Copy link
Author

jbenet commented Mar 9, 2017

Example for ipfs.dag.ls

var IPFSAPI = require('ipfs-api')
var ipfs = IPFSApi('/ip4/127.0.0.1/tcp/5001')

// given an object such as: 
//
// var obj = {
//     "a": 1,
//     "b": [1, 2, 3],
//     "c": {
//         "ca": [5, 6, 7],
//         "cb": "foo"
//     }
// }
// 
// ipfs.dag.put(obj, function(err, cid2) {
//     assert(cid == zdpuAkxd9KzGwJFGhymCZRkPCXtBmBW7mB2tTuEH11HLbES9Y)
// })

ipfs.dag.ls('zdpuAkxd9KzGwJFGhymCZRkPCXtBmBW7mB2tTuEH11HLbES9Y', function(err, result) {
    for (var i in result.entries) {
        console.log(result.entries[i])
    }
})
// Returns:
// a
// b
// c

ipfs.dag.ls('zdpuAkxd9KzGwJFGhymCZRkPCXtBmBW7mB2tTuEH11HLbES9Y/c', function(err, result) {
    for (var i in result.entries) {
        console.log(result.entries[i])
    }
})
// Returns:
// ca
// cb

ipfs.dag.ls('zdpuAkxd9KzGwJFGhymCZRkPCXtBmBW7mB2tTuEH11HLbES9Y/c/ca', function(err, result) {
    for (var i in result.entries) {
        console.log(result.entries[i])
    }
})
// Returns:
// 0
// 1
// 2

@jbenet
Copy link
Author

jbenet commented Mar 9, 2017

Example: ipfs.dag.tree

var IPFSAPI = require('ipfs-api')
var ipfs = IPFSApi('/ip4/127.0.0.1/tcp/5001')

// given an object such as: 
//
// var obj = {
//     "a": 1,
//     "b": [1, 2, 3],
//     "c": {
//         "ca": [5, 6, 7],
//         "cb": "foo"
//     }
// }
// 
// ipfs.dag.put(obj, function(err, cid2) {
//     assert(cid == zdpuAkxd9KzGwJFGhymCZRkPCXtBmBW7mB2tTuEH11HLbES9Y)
// })

ipfs.dag.tree('zdpuAkxd9KzGwJFGhymCZRkPCXtBmBW7mB2tTuEH11HLbES9Y', function(err, result) {
    for (var i in result) {
        console.log(result[i])
    }
})
// Returns:
// a
// b
// b/0
// b/1
// b/2
// c
// c/ca
// c/ca/0
// c/ca/1
// c/ca/2
// c/cb

ipfs.dag.tree('zdpuAkxd9KzGwJFGhymCZRkPCXtBmBW7mB2tTuEH11HLbES9Y/c', function(err, result) {
    for (var i in result) {
        console.log(result[i])
    }
})
// Returns:
// ca
// ca/0
// ca/1
// ca/2
// cb

@whyrusleeping
Copy link

I'm not so sure i like the way dag ls works. It doesnt give you any indication if you can list down that path further. It seems to me like we might as well just use ipfs dag tree. I implemented ls and when playing with it found myself constantly 'get'ing the object again to remember what paths i could play with

@daviddias daviddias mentioned this issue Mar 9, 2017
3 tasks
@daviddias daviddias added the ready label Mar 9, 2017
@daviddias
Copy link
Contributor

From using it, I can see what @whyrusleeping issue when using ls is.

I'm adding to tree a --recursive to explicitly declare that we want to traverse through the graph or stop at the first node. This way, a user can always check what it can get under a certain CID, without having to pay the cost of traversing an entire graph. Another option to implement this is to have --level, being --level=0 equal to --recursive=false and having a default of --recursive=true. I like both.

@dignifiedquire
Copy link
Contributor

I think level would be more interesting, as I can see a use case where you want to just know the next level down, but not traverse everything, which you can't do with the recursive flag.

@daviddias
Copy link
Contributor

@vmx ^^

@vmx vmx self-assigned this Jan 12, 2018
vmx added a commit to ipld/js-ipld that referenced this issue Nov 22, 2018
The whole IPLD APIs get a review to make them more consistent and
easier to use.

Changes to compared to the current spec:

 - No more callbacks, everything is Promises.
 - `get()`:
   - Is renamed to `resolve()` to indicate that it also takes a mandatory
     path argument.
   - Doesn’t have a `cid` in the return value anymore. That use case is
     covered by returning all objects that were traversed. Their `value`
     will always be the CID of the next one to traverse. So if you want
     to know the CID of the current IPLD Node, just look at the `value`
     of the previously returned IPLD Node.
   - Doesn’t return a single value, but an iterator.
   - `localResolve` option is removed. If you want to resolve a single IPLD
      Node only, just stop the iterator after the first item.
 - `getStream()` is removed without replacement. Use `resolve()` which uses
    async iterators instead.
 - `getMany()` is renamed to `get()`:
   - takes an iterable of CIDs as parameter.
 - `put()`:
   - takes an iterable of CIDs as parameter.
   - Doesn’t take `cid` as an option anymore. The CID is always calculated
     (#175).
   - The options don’t take the `format` (which is a string), but the `codec`
     (which is a `multicodec`) (#175).
   - the `version` option always defaults to `1`.
 - `.treeStream()` is removed without replacement (the only current user seems
   to be the IPFS DAG API tree command and the ipld-explorer-cli). IPLD Nodes
   are just normal JavaScript objects, so you can call `Object.keys()`
   recursively on a IPLD Node to get all its resolvable paths. If you want to
   follow all the CIDs, write the tree traversal yourself. This could perhaps
   be an example bundled with js-ipld.
 - `remove()`:
   - takes an iterable of CIDs as parameter.
 - `.support.add()` is renamed to `.addFormat()`.
 - `.support.rm()` is renamed to `.removeFormat()`.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

 - #66
   - [ ] IPLD Resolver `patch` API: There is no patch API yet
 - #70
   - [x] lazu value lookups: Can be done as IPLD Formats is pure JavaScript
   - [x] get external / local paths only: @vmx doesn’t know what this is,
         considers it a “won’t fix”
   - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
         => won’t fix
   - [ ] put + patch api #66: Patch API is still missing
   - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
   - [x] globbing: Out of scope for js-ipld
 - #175
   - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow
         `put()` with a CID
 - #182
   - [x] API Review: Links to many other issues, I list the individual issues
         below
 - #183
   - [x] getting the merkle proof with resolver.resolve: `resolve()` returns
         all CIDs along the traversed path
 - #184
   - [ ] Pass down the `options` object to resolver.resolve(): This needs a
         custom resolver. @vmx isn’t sure if the js-ipld API should make this
         possible, or of it should just be easy enough to create your own
         resolver.
 - https://github.com/ipfs/interface-ipfs-core/issues/81
   - [x] The `dag` API - One API to manipulate all the IPLD Format objects:
         Interesting discussion, but not relevant anymore.
 - ipfs-inactive/interface-js-ipfs-core#121
   - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as
         the IPLD Nodes are just JavaScript objects which you can easily traverse
         if you like. Though `tree()`-like functionality might be added as an
         example or separate module.
 - ipfs-inactive/interface-js-ipfs-core#125
   - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new
         `resolve()` API
 - ipfs-inactive/interface-js-ipfs-core#137
   - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld
         anymore. It should be considered if `tree()` is implemented (probably
         as an example or separate module)

Closes #182.
@vmx vmx mentioned this issue Nov 22, 2018
15 tasks
vmx added a commit to ipld/js-ipld that referenced this issue Nov 26, 2018
The whole IPLD APIs get a review to make them more consistent and
easier to use.

Changes to compared to the current spec:

 - No more callbacks, everything is Promises.
 - `get()`:
   - Is renamed to `resolve()` to indicate that it also takes a mandatory
     path argument.
   - Doesn’t have a `cid` in the return value anymore. That use case is
     covered by returning all objects that were traversed. Their `value`
     will always be the CID of the next one to traverse. So if you want
     to know the CID of the current IPLD Node, just look at the `value`
     of the previously returned IPLD Node.
   - Doesn’t return a single value, but an iterator.
   - `localResolve` option is removed. If you want to resolve a single IPLD
      Node only, just stop the iterator after the first item.
 - `getStream()` is removed without replacement. Use `resolve()` which uses
    async iterators instead.
 - `getMany()` is renamed to `get()`:
   - takes an iterable of CIDs as parameter.
 - `put()`:
   - takes an iterable of CIDs as parameter.
   - Doesn’t take `cid` as an option anymore. The CID is always calculated
     (#175).
   - The options don’t take the `format` (which is a string), but the `codec`
     (which is a `multicodec`) (#175).
   - the `version` option always defaults to `1`.
 - `.treeStream()` is removed without replacement (the only current user seems
   to be the IPFS DAG API tree command and the ipld-explorer-cli). IPLD Nodes
   are just normal JavaScript objects, so you can call `Object.keys()`
   recursively on a IPLD Node to get all its resolvable paths. If you want to
   follow all the CIDs, write the tree traversal yourself. This could perhaps
   be an example bundled with js-ipld.
 - `remove()`:
   - takes an iterable of CIDs as parameter.
 - `.support.add()` is renamed to `.addFormat()`.
 - `.support.rm()` is renamed to `.removeFormat()`.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

 - #66
   - [ ] IPLD Resolver `patch` API: There is no patch API yet
 - #70
   - [x] lazu value lookups: Can be done as IPLD Formats is pure JavaScript
   - [x] get external / local paths only: @vmx doesn’t know what this is,
         considers it a “won’t fix”
   - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
         => won’t fix
   - [ ] put + patch api #66: Patch API is still missing
   - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
   - [x] globbing: Out of scope for js-ipld
 - #175
   - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow
         `put()` with a CID
 - #182
   - [x] API Review: Links to many other issues, I list the individual issues
         below
 - #183
   - [x] getting the merkle proof with resolver.resolve: `resolve()` returns
         all CIDs along the traversed path
 - #184
   - [ ] Pass down the `options` object to resolver.resolve(): This needs a
         custom resolver. @vmx isn’t sure if the js-ipld API should make this
         possible, or of it should just be easy enough to create your own
         resolver.
 - https://github.com/ipfs/interface-ipfs-core/issues/81
   - [x] The `dag` API - One API to manipulate all the IPLD Format objects:
         Interesting discussion, but not relevant anymore.
 - ipfs-inactive/interface-js-ipfs-core#121
   - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as
         the IPLD Nodes are just JavaScript objects which you can easily traverse
         if you like. Though `tree()`-like functionality might be added as an
         example or separate module.
 - ipfs-inactive/interface-js-ipfs-core#125
   - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new
         `resolve()` API
 - ipfs-inactive/interface-js-ipfs-core#137
   - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld
         anymore. It should be considered if `tree()` is implemented (probably
         as an example or separate module)

Closes #182.
vmx added a commit to ipld/js-ipld that referenced this issue Feb 7, 2019
The whole IPLD APIs get a review to make them more consistent and
easier to use.

Changes to compared to the current spec:

 - No more callbacks, everything is Promises.
 - `get()`:
   - Is renamed to `resolve()` to indicate that it also takes a mandatory
     path argument.
   - Doesn’t have a `cid` in the return value anymore. That use case is
     covered by returning all objects that were traversed. Their `value`
     will always be the CID of the next one to traverse. So if you want
     to know the CID of the current IPLD Node, just look at the `value`
     of the previously returned IPLD Node.
   - Doesn’t return a single value, but an iterator.
   - `localResolve` option is removed. If you want to resolve a single IPLD
      Node only, just stop the iterator after the first item.
 - `getStream()` is removed without replacement. Use `resolve()` which uses
    async iterators instead.
 - `getMany()` is renamed to `get()`:
   - takes an iterable of CIDs as parameter.
 - `put()`:
   - takes an iterable of CIDs as parameter.
   - Doesn’t take `cid` as an option anymore. The CID is always calculated
     (#175).
   - The options don’t take the `format` (which is a string), but the `codec`
     (which is a `multicodec`) (#175).
   - the `cidVersion` option always defaults to `1`.
 - `.treeStream()` is renamed to `.tree()` and returns an async iterator.
 - `remove()`:
   - takes an iterable of CIDs as parameter.
 - `.support.add()` is renamed to `.addFormat()`.
 - `.support.rm()` is renamed to `.removeFormat()`.
 - `options.loadFormat()` is no longer callback based but is using an async
   function.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

 - #66
   - [ ] IPLD Resolver `patch` API: There is no patch API yet
 - #70
   - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript
   - [x] get external / local paths only: @vmx doesn’t know what this is,
         considers it a “won’t fix”
   - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
         => won’t fix
   - [ ] put + patch api #66: Patch API is still missing
   - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
   - [x] globbing: Out of scope for js-ipld
 - #175
   - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow
         `put()` with a CID
 - #182
   - [x] API Review: Links to many other issues, I list the individual issues
         below
 - #183
   - [x] getting the merkle proof with resolver.resolve: `resolve()` returns
         all CIDs along the traversed path
 - #184
   - [ ] Pass down the `options` object to resolver.resolve(): This needs a
         custom resolver. @vmx isn’t sure if the js-ipld API should make this
         possible, or of it should just be easy enough to create your own
         resolver.
 - https://github.com/ipfs/interface-ipfs-core/issues/81
   - [x] The `dag` API - One API to manipulate all the IPLD Format objects:
         Interesting discussion, but not relevant anymore.
 - ipfs-inactive/interface-js-ipfs-core#121
   - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as
         the IPLD Nodes are just JavaScript objects which you can easily traverse
         if you like. Though `tree()`-like functionality might be added as an
         example or separate module.
 - ipfs-inactive/interface-js-ipfs-core#125
   - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new
         `resolve()` API
 - ipfs-inactive/interface-js-ipfs-core#137
   - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld
         anymore. It should be considered if `tree()` is implemented (probably
         as an example or separate module)

Closes #70, #175, #182, #183
Closes ipfs-inactive/interface-js-ipfs-core#121
Closes ipfs-inactive/interface-js-ipfs-core#125
Closed ipfs-inactive/interface-js-ipfs-core#137
vmx added a commit to ipld/js-ipld that referenced this issue Feb 21, 2019
The whole IPLD APIs get a review to make them more consistent and
easier to use.

Changes to compared to the current spec:

 - No more callbacks, everything is Promises.
 - `get()`:
   - Is renamed to `resolve()` to indicate that it also takes a mandatory
     path argument.
   - Doesn’t have a `cid` in the return value anymore. That use case is
     covered by returning all objects that were traversed. Their `value`
     will always be the CID of the next one to traverse. So if you want
     to know the CID of the current IPLD Node, just look at the `value`
     of the previously returned IPLD Node.
   - Doesn’t return a single value, but an iterator.
   - `localResolve` option is removed. If you want to resolve a single IPLD
      Node only, just stop the iterator after the first item.
 - `getStream()` is removed without replacement. Use `resolve()` which uses
    async iterators instead.
 - `getMany()` is renamed to `get()`:
   - takes an iterable of CIDs as parameter.
 - `put()`:
   - takes an iterable of CIDs as parameter.
   - Doesn’t take `cid` as an option anymore. The CID is always calculated
     (#175).
   - The options don’t take the `format` (which is a string), but the `codec`
     (which is a `multicodec`) (#175).
   - the `cidVersion` option always defaults to `1`.
 - `.treeStream()` is renamed to `.tree()` and returns an async iterator.
 - `remove()`:
   - takes an iterable of CIDs as parameter.
 - `.support.add()` is renamed to `.addFormat()`.
 - `.support.rm()` is renamed to `.removeFormat()`.
 - `options.loadFormat()` is no longer callback based but is using an async
   function.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

 - #66
   - [ ] IPLD Resolver `patch` API: There is no patch API yet
 - #70
   - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript
   - [x] get external / local paths only: @vmx doesn’t know what this is,
         considers it a “won’t fix”
   - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
         => won’t fix
   - [ ] put + patch api #66: Patch API is still missing
   - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
   - [x] globbing: Out of scope for js-ipld
 - #175
   - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow
         `put()` with a CID
 - #182
   - [x] API Review: Links to many other issues, I list the individual issues
         below
 - #183
   - [x] getting the merkle proof with resolver.resolve: `resolve()` returns
         all CIDs along the traversed path
 - #184
   - [ ] Pass down the `options` object to resolver.resolve(): This needs a
         custom resolver. @vmx isn’t sure if the js-ipld API should make this
         possible, or of it should just be easy enough to create your own
         resolver.
 - https://github.com/ipfs/interface-ipfs-core/issues/81
   - [x] The `dag` API - One API to manipulate all the IPLD Format objects:
         Interesting discussion, but not relevant anymore.
 - ipfs-inactive/interface-js-ipfs-core#121
   - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as
         the IPLD Nodes are just JavaScript objects which you can easily traverse
         if you like. Though `tree()`-like functionality might be added as an
         example or separate module.
 - ipfs-inactive/interface-js-ipfs-core#125
   - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new
         `resolve()` API
 - ipfs-inactive/interface-js-ipfs-core#137
   - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld
         anymore. It should be considered if `tree()` is implemented (probably
         as an example or separate module)

Closes #70, #175, #182, #183
Closes ipfs-inactive/interface-js-ipfs-core#121
Closes ipfs-inactive/interface-js-ipfs-core#125
Closed ipfs-inactive/interface-js-ipfs-core#137
vmx added a commit to ipld/js-ipld that referenced this issue Mar 18, 2019
The whole IPLD APIs get a review to make them more consistent and
easier to use.

Changes to compared to the current spec:

 - No more callbacks, everything is Promises.
 - `get()`:
   - Is renamed to `resolve()` to indicate that it also takes a mandatory
     path argument.
   - Doesn’t have a `cid` in the return value anymore. That use case is
     covered by returning all objects that were traversed. Their `value`
     will always be the CID of the next one to traverse. So if you want
     to know the CID of the current IPLD Node, just look at the `value`
     of the previously returned IPLD Node.
   - Doesn’t return a single value, but an iterator.
   - `localResolve` option is removed. If you want to resolve a single IPLD
      Node only, just stop the iterator after the first item.
 - `getStream()` is removed without replacement. Use `resolve()` which uses
    async iterators instead.
 - `getMany()` takes an iterable as input now.
 - `put()`:
   - Doesn’t take `cid` as an option anymore. The CID is always calculated
     (#175).
   - The options don’t take the `format` (which is a string), but the `codec`
     (which is a `multicodec`) (#175).
   - the `cidVersion` option always defaults to `1`.
 - `.treeStream()` is renamed to `.tree()` and returns an async iterator.
 - `.support.add()` is renamed to `.addFormat()`.
 - `.support.rm()` is renamed to `.removeFormat()`.
 - `options.loadFormat()` is no longer callback based but is using an async
   function.
 - `putMany()` and `removeMany()` are introduced which both take an iterable
   as input.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

 - #66
   - [ ] IPLD Resolver `patch` API: There is no patch API yet
 - #70
   - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript
   - [x] get external / local paths only: @vmx doesn’t know what this is,
         considers it a “won’t fix”
   - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
         => won’t fix
   - [ ] put + patch api #66: Patch API is still missing
   - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
   - [x] globbing: Out of scope for js-ipld
 - #175
   - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow
         `put()` with a CID
 - #182
   - [x] API Review: Links to many other issues, I list the individual issues
         below
 - #183
   - [x] getting the merkle proof with resolver.resolve: `resolve()` returns
         all CIDs along the traversed path
 - #184
   - [ ] Pass down the `options` object to resolver.resolve(): This needs a
         custom resolver. @vmx isn’t sure if the js-ipld API should make this
         possible, or of it should just be easy enough to create your own
         resolver.
 - https://github.com/ipfs/interface-ipfs-core/issues/81
   - [x] The `dag` API - One API to manipulate all the IPLD Format objects:
         Interesting discussion, but not relevant anymore.
 - ipfs-inactive/interface-js-ipfs-core#121
   - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as
         the IPLD Nodes are just JavaScript objects which you can easily traverse
         if you like. Though `tree()`-like functionality might be added as an
         example or separate module.
 - ipfs-inactive/interface-js-ipfs-core#125
   - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new
         `resolve()` API
 - ipfs-inactive/interface-js-ipfs-core#137
   - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld
         anymore. It should be considered if `tree()` is implemented (probably
         as an example or separate module)

Closes #70, #175, #182, #183
Closes ipfs-inactive/interface-js-ipfs-core#121
Closes ipfs-inactive/interface-js-ipfs-core#125
Closed ipfs-inactive/interface-js-ipfs-core#137
vmx added a commit to ipld/js-ipld that referenced this issue Mar 18, 2019
The whole IPLD APIs get a review to make them more consistent and
easier to use.

Changes to compared to the current spec:

 - No more callbacks, everything is Promises.
 - `get()`:
   - Is renamed to `resolve()` to indicate that it also takes a mandatory
     path argument.
   - Doesn’t have a `cid` in the return value anymore. That use case is
     covered by returning all objects that were traversed. Their `value`
     will always be the CID of the next one to traverse. So if you want
     to know the CID of the current IPLD Node, just look at the `value`
     of the previously returned IPLD Node.
   - Doesn’t return a single value, but an iterator.
   - `localResolve` option is removed. If you want to resolve a single IPLD
      Node only, just stop the iterator after the first item.
 - `getStream()` is removed without replacement. Use `resolve()` which uses
    async iterators instead.
 - `getMany()` takes an iterable as input now.
 - `put()`:
   - Doesn’t take `cid` as an option anymore. The CID is always calculated
     (#175).
   - The options don’t take the `format` (which is a string), but the `codec`
     (which is a `multicodec`) (#175).
   - the `cidVersion` option always defaults to `1`.
 - `.treeStream()` is renamed to `.tree()` and returns an async iterator.
 - `.support.add()` is renamed to `.addFormat()`.
 - `.support.rm()` is renamed to `.removeFormat()`.
 - `options.loadFormat()` is no longer callback based but is using an async
   function.
 - `putMany()` and `removeMany()` are introduced which both take an iterable
   as input.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

 - #66
   - [ ] IPLD Resolver `patch` API: There is no patch API yet
 - #70
   - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript
   - [x] get external / local paths only: @vmx doesn’t know what this is,
         considers it a “won’t fix”
   - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
         => won’t fix
   - [ ] put + patch api #66: Patch API is still missing
   - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
   - [x] globbing: Out of scope for js-ipld
 - #175
   - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow
         `put()` with a CID
 - #182
   - [x] API Review: Links to many other issues, I list the individual issues
         below
 - #183
   - [x] getting the merkle proof with resolver.resolve: `resolve()` returns
         all CIDs along the traversed path
 - #184
   - [ ] Pass down the `options` object to resolver.resolve(): This needs a
         custom resolver. @vmx isn’t sure if the js-ipld API should make this
         possible, or of it should just be easy enough to create your own
         resolver.
 - https://github.com/ipfs/interface-ipfs-core/issues/81
   - [x] The `dag` API - One API to manipulate all the IPLD Format objects:
         Interesting discussion, but not relevant anymore.
 - ipfs-inactive/interface-js-ipfs-core#121
   - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as
         the IPLD Nodes are just JavaScript objects which you can easily traverse
         if you like. Though `tree()`-like functionality might be added as an
         example or separate module.
 - ipfs-inactive/interface-js-ipfs-core#125
   - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new
         `resolve()` API
 - ipfs-inactive/interface-js-ipfs-core#137
   - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld
         anymore. It should be considered if `tree()` is implemented (probably
         as an example or separate module)

Closes #70, #175, #182, #183
Closes ipfs-inactive/interface-js-ipfs-core#121
Closes ipfs-inactive/interface-js-ipfs-core#125
Closed ipfs-inactive/interface-js-ipfs-core#137
vmx added a commit to ipld/js-ipld that referenced this issue Mar 19, 2019
The whole IPLD APIs get a review to make them more consistent and
easier to use.

Changes to compared to the current spec:

 - No more callbacks, everything is Promises.
 - `get()`:
   - Is renamed to `resolve()` to indicate that it also takes a mandatory
     path argument.
   - Doesn’t have a `cid` in the return value anymore. That use case is
     covered by returning all objects that were traversed. Their `value`
     will always be the CID of the next one to traverse. So if you want
     to know the CID of the current IPLD Node, just look at the `value`
     of the previously returned IPLD Node.
   - Doesn’t return a single value, but an iterator.
   - `localResolve` option is removed. If you want to resolve a single IPLD
      Node only, just stop the iterator after the first item.
 - `getStream()` is removed without replacement. Use `resolve()` which uses
    async iterators instead.
 - `getMany()` takes an iterable as input now.
 - `put()`:
   - Doesn’t take `cid` as an option anymore. The CID is always calculated
     (#175).
   - The options don’t take the `format` (which is a string), but the `codec`
     (which is a `multicodec`) (#175).
   - the `cidVersion` option always defaults to `1`.
 - `.treeStream()` is renamed to `.tree()` and returns an async iterator.
 - `.support.add()` is renamed to `.addFormat()`.
 - `.support.rm()` is renamed to `.removeFormat()`.
 - `options.loadFormat()` is no longer callback based but is using an async
   function.
 - `putMany()` and `removeMany()` are introduced which both take an iterable
   as input.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

 - #66
   - [ ] IPLD Resolver `patch` API: There is no patch API yet
 - #70
   - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript
   - [x] get external / local paths only: @vmx doesn’t know what this is,
         considers it a “won’t fix”
   - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
         => won’t fix
   - [ ] put + patch api #66: Patch API is still missing
   - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
   - [x] globbing: Out of scope for js-ipld
 - #175
   - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow
         `put()` with a CID
 - #182
   - [x] API Review: Links to many other issues, I list the individual issues
         below
 - #183
   - [x] getting the merkle proof with resolver.resolve: `resolve()` returns
         all CIDs along the traversed path
 - #184
   - [ ] Pass down the `options` object to resolver.resolve(): This needs a
         custom resolver. @vmx isn’t sure if the js-ipld API should make this
         possible, or of it should just be easy enough to create your own
         resolver.
 - https://github.com/ipfs/interface-ipfs-core/issues/81
   - [x] The `dag` API - One API to manipulate all the IPLD Format objects:
         Interesting discussion, but not relevant anymore.
 - ipfs-inactive/interface-js-ipfs-core#121
   - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as
         the IPLD Nodes are just JavaScript objects which you can easily traverse
         if you like. Though `tree()`-like functionality might be added as an
         example or separate module.
 - ipfs-inactive/interface-js-ipfs-core#125
   - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new
         `resolve()` API
 - ipfs-inactive/interface-js-ipfs-core#137
   - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld
         anymore. It should be considered if `tree()` is implemented (probably
         as an example or separate module)

Closes #70, #175, #182, #183
Closes ipfs-inactive/interface-js-ipfs-core#121
Closes ipfs-inactive/interface-js-ipfs-core#125
Closed ipfs-inactive/interface-js-ipfs-core#137
vmx added a commit to ipld/js-ipld that referenced this issue Mar 21, 2019
The whole IPLD APIs get a review to make them more consistent and
easier to use.

Changes to compared to the current spec:

 - No more callbacks, everything is Promises.
 - `get()`:
   - Is renamed to `resolve()` to indicate that it also takes a mandatory
     path argument.
   - Doesn’t have a `cid` in the return value anymore. That use case is
     covered by returning all objects that were traversed. Their `value`
     will always be the CID of the next one to traverse. So if you want
     to know the CID of the current IPLD Node, just look at the `value`
     of the previously returned IPLD Node.
   - Doesn’t return a single value, but an iterator.
   - `localResolve` option is removed. If you want to resolve a single IPLD
      Node only, just stop the iterator after the first item.
 - `getStream()` is removed without replacement. Use `resolve()` which uses
    async iterators instead.
 - `getMany()` takes an iterable as input now.
 - `put()`:
   - Doesn’t take `cid` as an option anymore. The CID is always calculated
     (#175).
   - The options don’t take the `format` (which is a string), but the `codec`
     (which is a `multicodec`) (#175).
   - the `cidVersion` option always defaults to `1`.
 - `.treeStream()` is renamed to `.tree()` and returns an async iterator.
 - `.support.add()` is renamed to `.addFormat()`.
 - `.support.rm()` is renamed to `.removeFormat()`.
 - `options.loadFormat()` is no longer callback based but is using an async
   function.
 - `putMany()` and `removeMany()` are introduced which both take an iterable
   as input.

Almost all open issues in regards to the IPLD API got adressed. One bigger
thing is the Patch API, which also isn’t part of the current specification.
Here’s an overview of the issues:

 - #66
   - [ ] IPLD Resolver `patch` API: There is no patch API yet
 - #70
   - [x] lazy value lookups: Can be done as IPLD Formats is pure JavaScript
   - [x] get external / local paths only: @vmx doesn’t know what this is,
         considers it a “won’t fix”
   - [x] toJSON + fromJSON - roundtrip: A roundtrip is not a goal anymore
         => won’t fix
   - [ ] put + patch api #66: Patch API is still missing
   - [x] text summary: @vmx doesn’t see a strong use case for this => “won’t fix”
   - [x] globbing: Out of scope for js-ipld
 - #175
   - [x] Deprecate passing a CID to `ipld.put`?: Current spec doesn’t allow
         `put()` with a CID
 - #182
   - [x] API Review: Links to many other issues, I list the individual issues
         below
 - #183
   - [x] getting the merkle proof with resolver.resolve: `resolve()` returns
         all CIDs along the traversed path
 - #184
   - [ ] Pass down the `options` object to resolver.resolve(): This needs a
         custom resolver. @vmx isn’t sure if the js-ipld API should make this
         possible, or of it should just be easy enough to create your own
         resolver.
 - https://github.com/ipfs/interface-ipfs-core/issues/81
   - [x] The `dag` API - One API to manipulate all the IPLD Format objects:
         Interesting discussion, but not relevant anymore.
 - ipfs-inactive/interface-js-ipfs-core#121
   - [x] dag api: add {ls, tree}: `tree()` is not part of js-ipld anymore as
         the IPLD Nodes are just JavaScript objects which you can easily traverse
         if you like. Though `tree()`-like functionality might be added as an
         example or separate module.
 - ipfs-inactive/interface-js-ipfs-core#125
   - [x] `dag get --localResolve` vs `dag resolve`: This is solved by the new
         `resolve()` API
 - ipfs-inactive/interface-js-ipfs-core#137
   - [x] add `level` option to ipfs.dag.tree: `tree()` is not part of js-ipld
         anymore. It should be considered if `tree()` is implemented (probably
         as an example or separate module)

Closes #70, #175, #182, #183
Closes ipfs-inactive/interface-js-ipfs-core#121
Closes ipfs-inactive/interface-js-ipfs-core#125
Closed ipfs-inactive/interface-js-ipfs-core#137
@ghost ghost removed the ready label Mar 21, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants