3 ms·
The point I was trying to make was that the directory hierarchy isn't fundamental to how people reason about their data. That you could introduce a little UX ov
by smasher164 5y ago
The point I was trying to make was that the directory hierarchy isn't fundamental to how people reason about their data. That you could introduce a little UX over a KV store and those that wanted to mimic the old abstractions could continue to do so. But we could also change the abstractions (like the blog post says) to something like tags, and it wouldn't be any lower or higher level, compared to what we have now.
- theamk 5y agoAll the "tags" systems I have seen rely on some underlying store -- like in database-based methods, there is main table data (K-V store) and indices (another K-V store); or in symlink-based tags, we use underlying filesystem as data store. So the fundamental filesystem abstraction is K-V store. For efficiency reasons, based on common access pattern, this is often (but not always) implemented as a special kind of a tree. The tags system builds on that and thus is higher level -- even in the Didgets, the main primitive is "open by id", an example of K-V store operations. The whole tags thing is a way to query that store. The hierarchical filesystem also build on that -- but this time the key is (almost) arbitrary string, and the search operator does /-delimited prefix match. There is no real abstraction change when we move from hierarchical files to tags. There is still same old underlying K-V, but we just added an alternative to readdir() (and maybe also forced every file to live in root directory)