Good points.
but that form of structuring has been imposed by the nature of directories/files. I am not sure what the right solution would be for that case, perhaps internal tags for a set, but that would make things complicated.
In the nature of sets, maybe this could be done: "Source Code", "Shared With XYZ", "Application1"
Sharing could be defined on the set, "Shared With XYZ" is a tag that when defined could have the permissions etc. When a file is "placed in it", it is automatically shared.
We need to get detached from hierarchical thinking to see the possibilities, which is difficult as it is all present.
Maybe some sort of namespacing on tags would fix that; ie. so that your 'conf' tag for a software project doesn't conflict with the system 'conf' tag, which may have a different set of permissions.
Re:Set Based Filesystem idea
by silentbicycle on Friday July 17, 2009 @01:02PM
(#710270)
In practice, you would probably have different filesystem tables, so that system:conf+share/filename would be distinct from projects:conf+share/filename. The meaning of the same tag may be different in different contexts.
src/share/test.cpp share/src/test.cpp
Also certain implicit build systems, rely on the hierarchy to know what is parent, and what is child. You lose that with sets.
I still think it's cool idea, but not for all of your documents...
Besides how would you deal with sharing, inheriting security attributes, etc?
If I have
share/test/something.cpp and share is shared to everyone, would
test/share/something-else.cpp got shared too the same way as the first one?