> 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.
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.