This is a super nice idea. I wonder what other software we could interact in this form. The Unix people did have a good point about everything being a file.
I've also been considering some sort of filesystem for MQTT, which combined with an appropriate bridge would allow for reading and control of assorted smart devices as a filesystem.
A data type aware interface like AppleScript or COM, if universally supported, would be more expedient.
And so? The mantra says "everything is a file", not "everything is only a file". You can provide stream access to everything, and then more advanced access to some particular resources.
Providing just a generic interface cuts two ways: On the one hand, you can represent anything, but on the other hand, you don’t know what anything represents without additional information (metadata).
cat /mnt/imdb/movies/tt0103064/director/details.json
cat /mnt/imdb/actors/by_contains_name/arnold/roles.csv
Four fake file systems! (9 mins) https://www.youtube.com/watch?v=pfHpDDXJQVg
i.e. screenshots, torrents, youtube, git.
Yes and no. While it simplifies things to an extent, it's also confusing, especially with extension-less files.
Example: Tell me, is this a file or directory?
~/hn/today-posts
/dev/readme.dev
To know what this is, a `stat(2)` is required.
It gets worse when you deal with sysfs or procfs and similar. It all becomes obscure magic, like what values can be written into what file, why some files aren't readable, or the contents of files being just a bunch of numbers which you have no way of interpreting.
Another problem is that there's way too many of different file types and they aren't organized into any kind of hierarchy or any other meaningful order. This makes tools like rsync extremely complicated, with loads of footguns and still not solving the problem well. It feels especially bitter because in exceeding majority of cases you don't want tools like rsync to deal with named FIFO or device files or sockets etc. but you get accidentally but painfully bitten by them every now and then.
A directory is a file (and IIRC e.g. Plan 9 decided they should be readable just like normal files and there shouldn't be any special readdir syscalls). You can see its attributes to figure out the rest.
If not for strong Linux limitations (because of alleged hardlink knot-tying problem) and belief that it just cannot be both, transparent archive access through a filesystem would be a thing. As well as metadata access (`play ./file.mp3` vs `edit ./file.mp3/id3v2`). People of the past seemed to have paid great attention to interoperability and effort to make common interfaces; folks of the modern age ('00s and later) love unique and completely incompatible solutions to the same problem.
This was possible in the beginning. But then came the moral police and deprived us of this freedom, because they deemed it to be "confusing".
See, for example, The Unix Programming Environment, by Kernighan and Pike, page 51 [0]:
Despite their fundamental properties inside the kernel, directories sit in the file system as ordinary files. They can be read as ordinary files. (...) The time has come to look at the bytes in a directory:
$ od -cb .
stat(1) will provide additional information on a file.
file(1) will not only distinguish between filesystem=level distinctions, but will make a remarkably good guess as to what the file contents of a normal file are, based on magic(5).