You win by a few seconds…
1 Like
Then a directory is a container. That’s perfect for me: uniqueness is solved and this is analog to what was done with SDs (but this is not what is described in the text I quoted)
Thanks for the link, I was not aware of that limitation, must have been added after I last saw the mapped data draft.
That is troubling indeed. I tried to figure out where it came from and the reasons behind it (as well as whether that might be possible to lift it), because I wholly agree: a hundred files are nothing. Wasn’t able to find much in the internal discussions, will ask the routing team tomorrow, trying to find some answers.
Well, kinda. There are no directories - those are purely virtual. The container could also be stored under a/b/mycontainer.txt. While it’s recommended, it is not prevented either (at least not as part of this RFC). It would just come back as something you can read or write because it is a container rather than a file. So, I guess in an emulation it would show that entry as a non-file-entry. And you could open the address stored there as a new container.
I agree that what you want to achieve is there and can be achieved. I think this is just semantics, meaning and language at this point that gets a little in the way (as we removed the notion of directory in the first place). But essentially yes: putting containers into container is totally possible and explicitly allowed.
2 Likes
These numbers are just an initial limitation btw as in to start off with in testnets when the approach can firstly get verified. The RFC probably needs to get edited to make this one more clear. They by no means should indicate what we aim for permanently. They should currently allow the data type and its associated functionality get tested to start with before scaling the capacities such as any listed in the “Limits” section. Similar points can also get made for the number of parallel mutations a container might accept for a given entry or …
The main potential concern with having no limits to start off with in terms of the count would be with data concentration and some groups holding MutableData thereby getting lot more disproportionate chunk store sizes and thereby influence churn duration as churn operates per entry as detailed in the RFC. While these can be handled in a few ways to spread the data seamlessly to the user, they still need analysed and then discussed in an iteration as they aren’t flushed out yet.
Also as far as the type itself goes. It doesnt necessarily force “whole filesystem” in a single MutableData I’d think. MutableData can still get turned into a linked list if needed where the last entry points to the next MutableData as a continuation and so on even with this size limit or achieve the SD equalent of nested directories if needed too. This ofcourse isnt going to get the “lookup” across the entire data set if nested/linked so a choice depending on use-case may apply.
2 Likes
Hi all,
Ammendment proposal from @happybeing:
Re-opening this as I probably was too hasty closing it previously… you’re all going to see a lot more notifications from me going forward now as we reboot the RFC discussions (#sorrynotsorry).
DG.
1 Like