4 ms·
I don't know enough about filesystems to speak as to whether it's a good or bad design, but I quite like the concept. Cool work!
by Shared404 6y ago
I don't know enough about filesystems to speak as to whether it's a good or bad design, but I quite like the concept.
Cool work!
- eyelidlessness 6y agoIt’s a great design for certain use cases and fundamentally incompatible with/needs adaptation for others. It’ll work well for: - Aggregate workflows (i.e. composing heterogeneous collections) - Library curation (i.e. individual or mass categorization) - Content discovery/rediscovery (i.e. find things based on metadata rather than location) It’ll either poorly serve or need additional consideration for: - Contained dependencies (i.e. any kind of encapsulated package that has internal references) - Structural authorization (i.e. a given user may or may not be permitted access to some or all functions based on the branch/leaf they’re trying to access) - Structural layout (i.e. the user has a hierarchy in mind which they wish to reify)
- eyelidlessness 6y agoI’ll leave the above comment intact from here but I already edited once and still regret the word choice “fundamentally incompatible”. As with any data structure, you can make adaptations and accommodations to support use cases that seem to conflict. There’s always a memory/performance/impedance mismatch/experience cost for any abstraction, but there’s no reason a set/tree hybrid couldn’t provide for both families of use cases, given those costs.