design: add an exploration report about learning IPLD #294
Conversation
| different than Schemas. I found the "Mapped to the Data Model" introduction to | ||
| ADLs much easier to understand, as it shows reasonable examples. | ||
|
|
||
| * Why are multi-block data structures a separate definition in the spec, and not |
There was a problem hiding this comment.
This is historical - those docs were before schemas were materialised in doc form, but I think once we have a functioning end-to-end system that can do ADLs (go-ipld-prime being the obvious candidate for getting that done first) then we might have fresh eyes for revising how these pieces fit together. I don't envy you having to get up to speed with some of these concepts still being thought-bubbles and nowhere to be found code while we're all convince that they will be soon!..
|
Friendly ping @mikeal :) |
|
|
||
| * Wouldn't removing the first byte from a very long multi-block List mean that | ||
| every block would need to be modified to shift all bytes forward by one? I | ||
| assume and hope not, but the spec doesn't really give pointers. |
There was a problem hiding this comment.
Not sure if this was answered elsewhere, but the design of the ADL is where you resolve this concern. Some designs would cause the level of churn you’re stating but other designs can avoid most of it. For instance, if the primary concern is the cost of append-only mutations you can avoid generating any garbage at all using a design not unlike a blockchain.
| assume and hope not, but the spec doesn't really give pointers. | ||
|
|
||
| * Since data in blocks is encoded from the data model, how would Iknow if a | ||
| particular data model value fits in a single block? What about a shema value? |
There was a problem hiding this comment.
Depends on the codec how predictable the serialization is. If you are doing this in a codec agnostic way then you end up having to serialize it to get the size.
|
|
||
| * Would IPLD be much different if the data model was an internal detail, and not | ||
| exposed to the user? I imagine that, most of the time, one would interact with | ||
| schemas and not the data model. |
There was a problem hiding this comment.
Since these are all just protocols you have to keep in mind how a-la-carte people will choose to adopt them. Data encoded by one actor using a schema may be decoded by another actor who has little interest in the schema and can accomplish what they want with just the encoded data, and they may not even implement a full featured deserializer in order to do that.
| * When docs say "the IPLD type system", is that in terms of Schemas, or the Data | ||
| Model, or both? Answer: The schema intro later says that "types" are for | ||
| schemas, and "kinds" for the data model. That should probably be sooner in the | ||
| schema spec. |
There was a problem hiding this comment.
I’d need a link to the usage to answer this.
|
Left some comments we can follow up on, merging. |
No description provided.