WIP: new ipld format api #105
Conversation
BREAKING CHANGE: The IPLD Formats API is all new See https://github.com/ipld/interface-ipld-format/ for the current specification
All tests except for named links pass.
Named links are now also available through a properties directly on the DAGNode object. This makes IPFS-style traversals possible.
Only the newly proposed IPLD Format API is left.
There were dependencies which are no longer needed or are devDependencies now.
ghost
assigned 
Codecov Report
@@ Coverage Diff @@
## master #105 +/- ##
=========================================
- Coverage 91.35% 90.75% -0.6%
=========================================
Files 13 13
Lines 266 238 -28
=========================================
- Hits 243 216 -27
+ Misses 23 22 -1
Continue to review full report at Codecov.
|
|
If we're reviewing the API, let's remove the It's unreliable, expensive to calculate and leaks serialization details into the application layer. |
|
What's the thought behind using I'm looking at performance optimisations and our protobuf serialization is a very hot code path so will be looking at that soon. I don't want to spend time optimising the wrong module! |
The main reason was that I didn't want a dependency on Node.js Buffers but be able to use ArrayBuffers. I also prefer not to maintain forks of something. In addition to that the mapbox folks (who are maintaining pbf) really know what they are doing. And finally I preferred having the schema compiled once and committed rather then doing it on load/runtime. |
|
If the Obviously if this module starts emitting |
|
Superseded by #127. |
This is an implementation of the new IPLD Format API. It hopefully shows that although the public API changes a lot, the changes make sense and it won't be too hard to upgrade.
The resolver is completely gone, all enumerable properties are the public API to resolve through now. See the
resolver.spec.jstest for how things work now.