That's one of the few times I've read about a proposed innovation "in the spirit of UNIX" that was not already present in the original UNIX or one of its descendants.
UNIX: Everything is a file.
=> A directory is a file.
Parent post: Everything is a directory.
A file is a directory.
I.e., a switch from "There are files and special files called directories that are handled differently." to the recursive definition "There are files, which are made up of 0..n files (blobs) and 0..n subdirectories" - so file versus directory is just a VIEW.
Makes sense & would make writing traversal code for files wiht internal structure much easier to read and write.
> to the recursive definition "There are files, which are made up of 0..n files (blobs) and 0..n subdirectories"
I think, it's more like "a file node contains metadata, a binary blob of data (may be empty), and 0..n child files".
Agreed that this idea is very elegant and removes special cases, nodes become uniform. And the argument for reusing the OS(FS)-provided tree abstraction is compelling.
Although, I can imagine some performance concerns in the real world. If implemented naively and similarly to the existing Unixes, this model results in a lot of small fragmented blocks and separate syscalls+descriptors for dealing with each small file. Also, when the "tree" is actually a sequential array of nameless elements, there's some extra overhead involved with writing and storing made-up file names, as well as sorting by name when reading. This could be remedied by some new API. And a single tree implementation reused by everything could be more cache-friendly than having a userland parser for every "old" format in every application.
Anyway, this mental model is useful and I'd like to see and try out the "automounting" that the author describes.
Can't edit the parent comment anymore, so I'll append my other thoughts here.
I remembered that the "automounting" already exists in some forms, and I really like these instances. When you click on an archive in a good file manager, it opens a "folder" view with the archive contents. The difference between an archive and a folder is arbitrary. It shouldn't exist and only complicates things for everybody. I assume that many applications today hand-code the logic for "if the user drags and drops a folder, we need to zip it before sending". Or they don't, and the user has to zip manually :)
One could say that storing program data as "transparent" folders instead of "opaque" binary files is too much detail for the user. And users can accidentally damage something (e.g. delete one of the files inside) more easily. But I have a few counter-points:
1. Many applications already use folders, but they're doing fine.
2. File managers already open many filetypes in an editor by default (e.g. plain text, office docs), but these files are doing fine.
3. A good file manager should recognize most file types and do the more reasonable and safe thing. If JPEG is reimplemented as a folder, clicking on a JPEG should still open the image viewer instead of the folder view. That's already the case with Mac OS app bundles (the example from the original post).
4. Actually, now that folders have a "data" field, it can be used for storing arbitrary metadata. This is extremely powerful and can be used for HIDING extra details from casual users! E.g. there could be a standartized metadata header that hints to the file manager that it should treat the folder as an "opaque" file and not show the user the contents. Now, old applications that already used folders for their internal state, can mark these folders as "opaque" and prevent casual users from messing with the contents! While still allowing to see, move and delete the folder as a whole (unlike hidden folders). And while providing uniform FS access to applications and advanced users.
Man, I really like this idea of arbitrary metadata for folders... It's not as necessary for files, because in practice you can just put the "metadata header" in the beginning of the main "data" (as many file formats do).
That's one of the few times I've read about a proposed innovation "in the spirit of UNIX" that was not already present in the original UNIX or one of its descendants.
I.e., a switch from "There are files and special files called directories that are handled differently." to the recursive definition "There are files, which are made up of 0..n files (blobs) and 0..n subdirectories" - so file versus directory is just a VIEW.Makes sense & would make writing traversal code for files wiht internal structure much easier to read and write.
> to the recursive definition "There are files, which are made up of 0..n files (blobs) and 0..n subdirectories"
I think, it's more like "a file node contains metadata, a binary blob of data (may be empty), and 0..n child files".
Agreed that this idea is very elegant and removes special cases, nodes become uniform. And the argument for reusing the OS(FS)-provided tree abstraction is compelling.
Although, I can imagine some performance concerns in the real world. If implemented naively and similarly to the existing Unixes, this model results in a lot of small fragmented blocks and separate syscalls+descriptors for dealing with each small file. Also, when the "tree" is actually a sequential array of nameless elements, there's some extra overhead involved with writing and storing made-up file names, as well as sorting by name when reading. This could be remedied by some new API. And a single tree implementation reused by everything could be more cache-friendly than having a userland parser for every "old" format in every application.
Anyway, this mental model is useful and I'd like to see and try out the "automounting" that the author describes.
Can't edit the parent comment anymore, so I'll append my other thoughts here.
I remembered that the "automounting" already exists in some forms, and I really like these instances. When you click on an archive in a good file manager, it opens a "folder" view with the archive contents. The difference between an archive and a folder is arbitrary. It shouldn't exist and only complicates things for everybody. I assume that many applications today hand-code the logic for "if the user drags and drops a folder, we need to zip it before sending". Or they don't, and the user has to zip manually :)
One could say that storing program data as "transparent" folders instead of "opaque" binary files is too much detail for the user. And users can accidentally damage something (e.g. delete one of the files inside) more easily. But I have a few counter-points:
1. Many applications already use folders, but they're doing fine.
2. File managers already open many filetypes in an editor by default (e.g. plain text, office docs), but these files are doing fine.
3. A good file manager should recognize most file types and do the more reasonable and safe thing. If JPEG is reimplemented as a folder, clicking on a JPEG should still open the image viewer instead of the folder view. That's already the case with Mac OS app bundles (the example from the original post).
4. Actually, now that folders have a "data" field, it can be used for storing arbitrary metadata. This is extremely powerful and can be used for HIDING extra details from casual users! E.g. there could be a standartized metadata header that hints to the file manager that it should treat the folder as an "opaque" file and not show the user the contents. Now, old applications that already used folders for their internal state, can mark these folders as "opaque" and prevent casual users from messing with the contents! While still allowing to see, move and delete the folder as a whole (unlike hidden folders). And while providing uniform FS access to applications and advanced users.
Man, I really like this idea of arbitrary metadata for folders... It's not as necessary for files, because in practice you can just put the "metadata header" in the beginning of the main "data" (as many file formats do).