Yes I'm saying the Unix file system is a worse mongodb. Please at least give me a postgres or something.
Yes I'm saying the Unix file system is a worse mongodb. Please at least give me a postgres or something.
Maybe I've completely misunderstood your proposition, though.
Now, that doesn't stop MyProprietaryApp from declaring that the type MyProprietaryFile consists of a big bucket of bytes which it then interprets how it likes, but that's inevitable and not worth worrying about.
The point is to enable defining directory and file schemas for my OS and applications that I can control so that interaction and discovery within these systems isn't so baroque.
Everything in 'special' mounted filesystems like procfs, sys, cgroupsv2, etc as a start. These all use implicit schemas of particularly named files with particular contents that you have to learn about out-of-band to just to do anything.
Requirement 1: Everything has an inspectable schema.
All the configuration files with their own home-grown format that you can only validate by restarting the program that relies on it and hoping that it doesn't crash your system is for the birds.
Requirement 2: Files that must have a particular format must also have a well-defined Type that can be validated to be correct in a uniform way outside the program that uses it.
Isn't that exactly how traditional FS work anyway? Even using MIME types only gives you an optional, non-binding hint. In the end you need to parse and interpret the content "manually" (well, usually using libraries).
> parse everything manually just to interpret it: not so great.
Except the first sentence, the first paragraph describes current filesystem design.