feat(linksystem): add reification to LinkSystem #158
Conversation
add an optional reifier into the link system process. The reason to do this is to capture the link system itself when reification happens, in case it needs to be put into the node, which is often not accessible by the time you have a node. another alternative would be to make this specific to selector traversal, similar to LinkNodePrototypeChooser
|
leaving storage off entirely for this pass seems like a good delineation to draw in helping focus this conversation. |
|
Hm, this is really interesting! The example of applying this with the rot13adl demo is a little boring, because it's just unconditionally calling reify on the thing -- but I think I see where you're going with this. One could use the LinkContext to make choices about where to apply an ADL based on content (like the parent path, or etc), or just inspecting the data in the Node for some pattern. The NodeReifier function then handles both "the signalling problem" from that information (e.g. decide if there's an ADL at all) and "the implementation reference problem" (the answer is "whatever's linked by this function"). Nice. |
|
One thought I'm kind of turning over in my head if this seems like something that belongs attached statefully to the LinkSystem, or if it's something that would be cleaner as another variation of Load function with this NodeReifier as an argument. But that's probably more of a stylistic question than a practical functional one. |
I'm struggling to imagine how I would ever use this feature. Is what you say here a good example? For instance, with go-ipld-adl-hamt, I think I'd just always want to use the ADL's nodes, so extra logic doesn't seem necessary. |
|
The idea is that you could use the NodeReifier to decide what ADLs to use and when, even when in the middle of a traversal. So, you could write a NodeReifier that says "okay, when I'm in a path that ends with 'foosys/bar/hamt', i'm going to try to load that as if it's a HAMT ADL". And then you'd be able to walks over whole trees with |
|
Did an additional informal poll on Slack about this and it got only 🎉 and 👍 emoji, so, let's roll. |
Goals
Proposal for how to integrate ADL creation into the LinkSystem loading process
Implementation
Add an optional reifier into the link system process to create ADLs. The reason to do this is to capture the link
system itself when reification happens, in case it needs to be put into the node, which is often not
accessible by the time you have a node.
Another alternative would be to make this specific to
selector traversal, similar to LinkNodePrototypeChooser
For Discussion
I actually left off Storage as a concern entirely. The simple version would be to just make a NodeSubstrater function with a shape like this:
But in reality a Store operation on an ADL Node built with some kind of ADL builder (think HAMT) actually probably stores SEVERAL blocks. I'm not sure the absolute best way to do that. Technically, such a NodeBuilder could store its "sub blocks" on NodeBuilder.Build... but that also feels a bit odd since one does not expect that operation to store
Another option would be for NodeBuilder to assemble a bunch of nodes as needed in a temporary store, and then for the Store to move it to the actual blockstore? Hard to say.