Roadmap #3
Roadmap #3
Conversation
|
If I understand correctly, a couple of the directory read ADL checkboxes will also be done in the very near future already 👼 |
| - ADL to make files appear as `kind`==`bytes`, where interally layout=trickledag: | ||
| - [ ] Readable | ||
| - [ ] Writable | ||
| - [ ] Chunker as a callback/interface | ||
| - (may choose to implement this as mostly shared code with the other file ADL, where the internal layout is just a parameter; undecided) | ||
| - [ ] Upstream work to determine how `ipld.Node` and `ipld.NodeAssembler` should work for data in the size scale that requires streaming and seeking | ||
| - ADL to make files appear as `kind`==`bytes`, where interally layout=balanceddag: |
There was a problem hiding this comment.
where interally layout=trickledag
where interally layout=balanceddag
Hm... the wording confuses me: Is the above only applicable to the writer ( for obvious reasons ), or does this apply to the reader as well? That is - can an ADL be written which reads arbitrary arrangements of UnixFS nodes, as originally intended way way back?
There was a problem hiding this comment.
Probably the writers are different and the readers end up being the same. But I didn't want to be prescriptive about how it's implemented. Easy enough to check two boxes at once if the implementer ends up nailing both goals with the same code.
There was a problem hiding this comment.
Postel violation though. I want go-ipfs to continue being able reading dags created by something that's not go-ipfs.
There was a problem hiding this comment.
I don't understand what in this wording gives the impression that that will somehow get harder as a result of this work, but if there is such a miswording, I'm open to fixing it.
|
I think this may need an updated to check more of the boxes that have now already become done, but I would otherwise like to merge this :) (I think think it may become something to link to in near-future project proposals, too.) |
These are just my current thoughts on what we could do with a bunch of ADLs, taking the idea of the code here now and running with it.
(It's possible that work can be done in the upstream before getting to it here... but equally if not more likely that the work in this repo should push the interface design, since that way we'll really know what we need from it.)
There was a problem hiding this comment.
@warpfork sorry I never followed up here but this looks LGTM though we should go back and update the check marks -- a lot of them are filled out now :)
Drafted a roadmap with my current thoughts on what we could do with a bunch of ADLs. It's taking the idea of the code here now and running with it.
I think I see roughly 4 or 5 things that could be a discrete useful ADL, and by putting them all together, I think we'd have a really slick way to handle unixfsv1 data.
I think these are things that would make sense to co-locate all in one repo, but this PR is also a discussion-starter for that, I guess.