I always disliked the file systems being hierarchical databases with the limitations they have.
Even from the simple, non programmer user (or a "power user") perspective I don't actually want the files the way they are. A file usually needs a name (which is not good for anything) and stores both the data and the metadata inside, a metadata correction automatically changes the file hash and the file system doesn't consider the fact most of my files (or at least the data part of them) are never meant to change (taking this fact in account could provide extra optimization and protection). Ideally a file should only store data (e.g. a pure sound stream for an audio file) + a collection of metadata fields (including tags!) I can query to find the files I need. AFAIK something like that was supposed to be implemented in WinFS but it was cancelled.
In fact you can use extended attributes/streams or even use SQLite as a file system (or a file format). But nobody does that. I feel interested in implementing a file manager to store all my files in SQLite and provide a convenient GUI to work with them but it seems too much work (I don't even have an idea of the UI) and its usefulness is going to be questionable as no application developed by others is going to be able to open files directly from that database anyway. Nevertheless it can be a good idea to use SQLite as a file system for particular projects like those you have described.
What I can conclude, however, is the idea we shouldn't choose one. Traditional FS should be kept there (for now at least, mostly because it's going to be an extremely hard to replace it with anything which would make more sense for the task) to store system files (and code files perhaps) + a better storage for user files (like pictures, videos, audios, documents etc) and this is mostly a matter of inventing a proper file manager. As for the projects where you are to store enormous numbers of files (so inode number limitation becomes a problem) like mentioned in the article there is little point in using a general purpose FS in the first place, one should either use a database or a raw hard drive (or a database on a raw hard drive).
If one application is able to use it or has a version able to use it the users of that application could format a drive for it. More applications could follow if the gains are big enough. Hardware could be created to fit better. Again, if the gains are big enough it is worth it. More applications will follow. Different things could migrate there like those SaaS like functions. Data could be shared between applications.
Inserting data A into B, serializing it into C, storing it as D then morph it back into C, turn it back into B again so that you can read A from it???
If A is 10 bytes, B is 10 GB OR we don't know if A exists in C? The ease of use and/or performance gain would be substantial even without memorizing 1000 manuals worth of exotic formats.
> its usefulness is going to be questionable as no application developed by others is going to be able to open files directly from that database anyway
Don't most operating systems provide for some kind of vfs nowadays? So you can indeed expose it as a legacy hierarchical filesystem if you want.
I guess the reason every extended database type filesystem has failed is the same one: basically, you need legacy support. Otherwise the user agents don't exist to access your data. Several older operating systems had support for attributes of various type and purpose, but they roughly died as the web became popular, because HTTP has no way to handle that problem.
The nearest exception is on handheld devices that run non-legacy operating systems, but then power users complain they don't have adequate control.
> but then power users complain they don't have adequate control.
They wouldn't if they were actually given adequate control. The problem of iOS is not the fact it doesn't expose a traditional file system, it's the fact it doesn't expose any and won't let you control the apps beyond the level Apple likes nor to sideload custom apps you or the free software community might have developed (which certainly isn't a 100% evil policy - it actually protects you from evil agents like the Chinese TSA which is known to install hidden apps on Android phones it searches). I couldn't even find a way to play OPUS audio files on a recent iPhone (despite the fact iPhone supports OPUS in hardware). As a power user I can be pretty well-satisfied without access to the file system if only the UIs and APIs above it provided the level of control and functionality I want.
Well, you convinced me. It's an interesting project idea.
Concerning user interface, I think the ordinary user interface of such a system would have to be application based. Rather than increasingly impure desktop metaphor, you simply list the applications available to user. They open the application and select from the available documents. You would have some kind of list of filters, including automatically maintained filters (like "time last opened") and manually maintained tags.
You could probably have a power users interface that is "the file manager". But it's just the normal file picker, without a default filter of "files i know how to open".
But you still have a problem when you export a file. How do you export that compressed audio stream when you want to send it to your friend? You need to identify all the metadata and reconstruct an MP3 file. Presumably you could implement version 0 of this without changing the file storage, since file importer/exporter is kinda crucial. So you just cache the important data somewhere.
It would all be more important if files were still as relevant as they used to be. I used to have ogg vorbis files and photos and everything. Nowadays, it's really only code and occasionally a document. Otherwise I'm in my web browser or on an app on my phone.
Even from the simple, non programmer user (or a "power user") perspective I don't actually want the files the way they are. A file usually needs a name (which is not good for anything) and stores both the data and the metadata inside, a metadata correction automatically changes the file hash and the file system doesn't consider the fact most of my files (or at least the data part of them) are never meant to change (taking this fact in account could provide extra optimization and protection). Ideally a file should only store data (e.g. a pure sound stream for an audio file) + a collection of metadata fields (including tags!) I can query to find the files I need. AFAIK something like that was supposed to be implemented in WinFS but it was cancelled.
In fact you can use extended attributes/streams or even use SQLite as a file system (or a file format). But nobody does that. I feel interested in implementing a file manager to store all my files in SQLite and provide a convenient GUI to work with them but it seems too much work (I don't even have an idea of the UI) and its usefulness is going to be questionable as no application developed by others is going to be able to open files directly from that database anyway. Nevertheless it can be a good idea to use SQLite as a file system for particular projects like those you have described.