I chose the filesystem paths organically as I was iterating with it: starting from the ideas of having a root dir and a simple unique "home" dir.
I also wanted to allow the visitor to hack around stuff like the system config through the filesystem (as if updating the `~/.config/` or `/etc/` directories in the linux world), so I also planned to have the desktop's own config files reachable in there and make it user-editable (though for now that's only the case for the list of desktop icons).
I found out that having a few root directories that were fully virtual[1] (actually in-memory) and marked a "read-only", and the others that were actually real IndexedDB-backed storage[2] was very simple to manage.
In the end it seemed to me like a much more simplified unix-like way of doing things which is what I'm the most used to.
I'm not that familiar with windows so I'm not sure why it also looks windows-like though :D, is it about the naming of paths?
[1] `/apps` for apps and `/system32` for default configs - the name was `/system` at first, then I thought renaming it `system32` instead was ""funny"" (as the directory name became kind of a meme), so I did that! Both store "files" that are actually JS objects that can be stringified to JSON when reading them.
[2] For now `/userconfig` for the desktop's own update-able config and `/userdata` for the "home" directory. Something like `/appconfig` is also planned though I'm not sure yet. In contrast those contain data really stored locally, in ArrayBuffer form (a blob of bytes).
I also wanted to allow the visitor to hack around stuff like the system config through the filesystem (as if updating the `~/.config/` or `/etc/` directories in the linux world), so I also planned to have the desktop's own config files reachable in there and make it user-editable (though for now that's only the case for the list of desktop icons).
I found out that having a few root directories that were fully virtual[1] (actually in-memory) and marked a "read-only", and the others that were actually real IndexedDB-backed storage[2] was very simple to manage.
In the end it seemed to me like a much more simplified unix-like way of doing things which is what I'm the most used to. I'm not that familiar with windows so I'm not sure why it also looks windows-like though :D, is it about the naming of paths?
[1] `/apps` for apps and `/system32` for default configs - the name was `/system` at first, then I thought renaming it `system32` instead was ""funny"" (as the directory name became kind of a meme), so I did that! Both store "files" that are actually JS objects that can be stringified to JSON when reading them.
[2] For now `/userconfig` for the desktop's own update-able config and `/userdata` for the "home" directory. Something like `/appconfig` is also planned though I'm not sure yet. In contrast those contain data really stored locally, in ArrayBuffer form (a blob of bytes).