> I think if someone went off and redesigned a global KV store for an OS they'd probably require authentication tokens for mutations, so your app would only be able to communicate with the subtrees of the store that it has permissions to (but also, kind of like a file system?)
If I had to design an OS from scratch, this is basically what I would do. I'd provide an API for a prefix-tree based KV store with specific data types (eg bytes, utf-8 string, bool, int, float, datetime...) with some mechanism for namespaces and path access controls or the like. Processes would always have their own space to use ad-lib, and would have controlled access to system-wide or cross-process spaces.
This sort of implementation lets you optimize access patterns so that basically each process gets its own KV/db (if it wishes) which should be roughly as performant as rolling its own kv running on the filesystem. Vs all processes all competing for the same data structure, all the time.
I agree with this. Although I would probably make it a pseudo file system and allow normal file reading (you want to dump as JSON? Read /etc/conf/app.json. TOML? /etc/conf/app.toml) as well as something like sysfs (/etc/conf/app/thing). The raw data itself can live at /mnt/conf.
The thing I'm not sure about is how you'd implement secure initialization/registration of a new app on first run.
Interestingly enough, the only thing that's missing from this design from the modern Windows Registry is the generation and usage of user principals. The registry already supports a rich, granular permission system, and enforced sandboxing for access. In a greenfield design, yeah, I could see your design being quite useful, but adapting and enforcing a usage pattern on current day Windows isn't that far off.
If I had to design an OS from scratch, this is basically what I would do. I'd provide an API for a prefix-tree based KV store with specific data types (eg bytes, utf-8 string, bool, int, float, datetime...) with some mechanism for namespaces and path access controls or the like. Processes would always have their own space to use ad-lib, and would have controlled access to system-wide or cross-process spaces.
This sort of implementation lets you optimize access patterns so that basically each process gets its own KV/db (if it wishes) which should be roughly as performant as rolling its own kv running on the filesystem. Vs all processes all competing for the same data structure, all the time.