This repository has been archived by the owner on Aug 11, 2021. It is now read-only.
Define how toJSON() should look like
#49
Labels
api-review
Tackle during the API review
Comments
vmx
added a commit
that referenced
this issue
Nov 22, 2018
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
vmx
added a commit
that referenced
this issue
Nov 22, 2018
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
removed
the
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
A
toJSON()method is useful to have an easy way to interoperate with other tools. You can easily export data out of IPLD as most tools/languages understand JSON.Though there should be guidelines on how data not natively support by JSON should be represented. For example binary data, but also CIDs.
For CIDs it would e.g. be possible to really split it into its separate parts. This way everyone consuming the JSON wouldn't need to be able to parse a CID, but could still get insight information about e.g. the coded.
The text was updated successfully, but these errors were encountered: