API review #48
Comments
|
Where is the current spec for IPLD? |
|
@richardschneider Most recent one is at ipld/specs#72 |
|
Before reviewing the API, I would like to see the IPLD use case(s) or a list of requirements. Are they available somewhere? |
|
Can we scope this to The use cases for IPLD are too numerous, we're effectively talking about building data-structures to support every application vertical. The case for The main purpose of the interface is to provide a codec agnostic way to interact with Blocks. The primary consumer is IPFS. It needs to be able to:
Limiting the scope of the interface is that it operates on a single block at a time. For path traversals, it only resolves the path available in a single block, returning enough information for the consumer to continue traversing the path through subsequent blocks. The interface is defined so that codecs can match the API and be plugged in to anything that consumes IPLD codecs. Note that, based on ipld/specs#72, this |
The whole IPLD APIs get a review to make them more consistent and easier to use. The biggest change is that there's not `resolve` API anymore. From now on you access the properties of the JavaScript objects directly. Issues that were taken into account: - #31 - [x] Remove `isLink()` method from formats: `isLink()` is no longer needed as all links will be CID objects you can easily check for - #44 - [x] Proposal: Move resolver to use CID instances for links: Not applicable anymore as `resolve.resolve()` is removed - #46 - [x] properties: align spec with implementation: Covered by spec - #49 - [x] Define how `toJSON()` should look like: Binary and CIDs are defined with example - #34 - [x] Implementation of nested objects: Won’t fix as `tree()` is not part of the API anymore Closes #48.
ghost
assigned
|
The current review is done. Some of the discussions of a next generation API happen over here https://github.com/ipld/js-ipld-stack. |
@mikeal and I want to review the current API and see how they can be made more ergonomic.
The goal is to have a nice to use and easy to implement API which aligns well with the current vision of IPLD. Breaking the API is possible and even very likely.
Currently also the spec and the format implementations are not in sync at the moment (see the open issues for more information).
Parts of it is that it will use async/await, hence aligns well with the Awesome Endeavour: Async Iterators.
We can use this issue for further discussion/referencing things.
/cc @hacdias
The text was updated successfully, but these errors were encountered: