You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Aug 11, 2021. It is now read-only.
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, #183Closesipfs-inactive/interface-js-ipfs-core#121Closesipfs-inactive/interface-js-ipfs-core#125Closedipfs-inactive/interface-js-ipfs-core#137
The IPLD API works strictly with CIDs and deserialized IPLD Nodes. Interacting with the binary data happens on lower levels. To access the binary data directly, use the [Block API](https://github.com/ipfs/interface-ipfs-core/blob/master/SPEC/BLOCK.md).
96
+
93
97
### IPLD constructor
94
98
95
99
> Creates and returns an instance of IPLD.
@@ -130,83 +134,97 @@ const ipld = new Ipld({
130
134
})
131
135
```
132
136
133
-
##### `options.loadFormat(codec, callback)`
137
+
##### `options.loadFormat(codec)`
134
138
135
139
| Type | Default |
136
140
|------|---------|
137
-
|`Function`|`null`|
141
+
|`async Function`|`null`|
138
142
139
-
Function to dynamically load an [IPLD Format](https://github.com/ipld/interface-ipld-format). It is passed a string `codec`, the multicodec of the IPLD format to load and a callback function to call when the format has been loaded. e.g.
143
+
Function to dynamically load an [IPLD Format](https://github.com/ipld/interface-ipld-format). It is passed a `codec`, the multicodec code of the IPLD format to load and returns an IPLD Format implementation. For example:
140
144
141
145
```js
146
+
constmulticodec=require('multicodec')
142
147
constipld=newIpld({
143
-
loadFormat (codec, callback) {
144
-
if (codec ==='git-raw') {
145
-
callback(null,require('ipld-git'))
148
+
asyncloadFormat (codec) {
149
+
if (codec ===multicodec.GIT_RAW) {
150
+
returnrequire('ipld-git')
146
151
} else {
147
-
callback(newError('unable to load format '+ codec))
152
+
thrownewError('unable to load format '+multicodec.print[codec])
148
153
}
149
154
}
150
155
})
151
156
```
152
157
153
-
### `.put(node, options, callback)`
158
+
### `.put(nodes, format, options)`
159
+
160
+
> Stores the given IPLD Nodes of a recognized IPLD Format.
161
+
162
+
-`nodes` (`Iterable<Object>`): deserialized IPLD nodes that should be inserted.
163
+
-`format` (`multicodec`, required): the multicodec of the format that IPLD Node should be encoded in.
164
+
-`options` is applied to any of the `nodes` and is an object with the following properties:
165
+
-`hashAlg` (`multicodec`, default: hash algorithm of the given multicodec): the hashing algorithm that is used to calculate the CID.
166
+
-`cidVersion` (`number`, default: 1): the CID version to use.
167
+
-`onlyHash` (`boolean`, default: false): if true the serialized form of the IPLD Node will not be passed to the underlying block store.
168
+
169
+
Returns an async iterator with the CIDs of the serialized IPLD Nodes.
170
+
171
+
172
+
### `.resolve(cid, path)`
173
+
174
+
> Retrieves IPLD Nodes along the `path` that is rooted at `cid`.
154
175
155
-
> Store the given node of a recognized IPLD Format.
176
+
-`cid` (`CID`, required): the CID the resolving starts.
177
+
-`path` (`IPLD Path`, required): the path that should be resolved.
156
178
157
-
`options` is an object that must contain one of the following combinations:
158
-
-`cid` - the CID of the node
159
-
-`[hashAlg]`, `[version]` and `format` - the hashAlg, version and the format that should be used to create the CID of the node. The
160
-
`hashAlg` and `version` defaults to the default values for the `format`.
179
+
Returns an async iterator of all the IPLD Nodes that were traversed during the path resolving. Every element is an object with these fields:
180
+
-`remainderPath` (`string`): the part of the path that wasn’t resolved yet.
181
+
-`value` (`*`): the value where the resolved path points to. If further traversing is possible, then the value is a CID object linking to another IPLD Node. If it was possible to fully resolve the path, `value` is the value the `path` points to. So if you need the CID of the IPLD Node you’re currently at, just take the `value` of the previously returned IPLD Node.
161
182
162
-
It may contain any of the following:
163
183
164
-
-`onlyHash` - If true the serialized form of the node will not be passed to the underlying block store but the passed callback will be invoked as if it had been
184
+
### `.get(cids)`
165
185
166
-
`callback` is a function that should have the signature as following: `function (err, cid) {}`, where `err` is an Error object in case of error and `cid` is the cid of the stored object.
186
+
> Retrieve several IPLD Nodes at once.
167
187
168
-
### `.get(cid [, path] [, options], callback)`
188
+
-`cids` (`Iterable<CID>`): the CIDs of the IPLD Nodes that should be retrieved.
169
189
170
-
> Retrieve a node by the given `cid` or `cid + path`
190
+
Returns an async iterator with the IPLD Nodes that correspond to the given `cids`.
171
191
172
-
`options` is an optional object containing:
192
+
Throws an error if a IPLD Node can’t be retrieved.
173
193
174
-
-`localResolve: bool` - if true, get will only attempt to resolve the path locally
194
+
### `.remove(cids)`
175
195
176
-
`callback` should be a function with the signature `function (err, result)`, the result being an object with:
196
+
> Remove IPLD Nodes by the given `cids`
177
197
178
-
-`value` - the value that resulted from the get
179
-
-`remainderPath` - If it didn't manage to successfully resolve the whole path through or if simply the `localResolve` option was passed.
180
-
-`cid` - Where the graph traversal finished - if `remainderPath` has a value, this will be where it has its root
198
+
-`cids` (`Iterable<CID>`): the CIDs of the IPLD Nodes that should be removed.
181
199
182
-
### `.getMany(cids, callback)`
200
+
Throws an error if any of the Blocks can’t be removed. This operation is not atomic, some Blocks might have already been removed.
183
201
184
-
> Retrieve several nodes at once
185
202
186
-
`callback` should be a function with the signature `function (err, result)`, the result is an array with the nodes corresponding to the CIDs.
203
+
### `.tree(cid, [path], [options])`
187
204
205
+
> Returns all the paths that can be resolved into.
188
206
189
-
### `.getStream(cid [, path] [, options])`
207
+
-`cid` (`CID`, required): the CID to get the paths from.
208
+
-`path` (`IPLD Path`, default: ''): the path to start to retrieve the other paths from.
209
+
-`options`:
210
+
-`recursive` (`bool`, default: false): whether to get the paths recursively or not. `false` resolves only the paths of the given CID.
190
211
191
-
> Same as get, but returns a source pull-stream that is used to pass the fetched node.
212
+
Returns an async iterator of all the paths (as Strings) you could resolve into.
192
213
193
-
### `.treeStream(cid [, path] [, options])`
194
214
195
-
> Returns all the paths under a cid + path through a pull-stream. Accepts the following options:
215
+
### `.addFormat(ipldFormatImplementation)`
196
216
197
-
-`recursive` - bool - traverse through links to complete the graph.
217
+
> Add support for an IPLD Format
198
218
199
-
### `.remove(cid, callback)`
219
+
-`ipldFormatImplementation` (`IPLD Format`, required): the implementation of an IPLD Format.
0 commit comments