I was thinking of a system where the content of the nodes is persisted as files, like in static website generators, and then the interactive view is generated from the content read in files when the application starts or is updated.
Wikis work that way, where the payload of each page is a flat text sequence with simple markup.
The structure, relations and metadata could then be stored in a serverless database, like Git does in the .git folder. Not perfect, but I think the benefits for personal information outweight the limitations.
> Wikis work that way, where the payload of each page is a flat text sequence with simple markup.
That depends on the wiki. The most well known - MediaWiki - uses traditional DB like MySQL or Postgres.
> The structure, relations and metadata could then be stored in a serverless database, like Git does in the .git folder. Not perfect, but I think the benefits for personal information outweight the limitations.
What happens when files and metadata go out of sync? People want to have the data in plaintext for interoperability with other tools so they are going to edit the data outside of the app. And your app does not know files changed so it can't selectively update the indexes/metadata.
Another motivation for flat files is that users want to use standard sync tools like syncthing, dropbox etc. But these metadata and indexes will not work at all in case of write conflicts - dropbox does not know how to merge those serverless database files.
> Wikis work that way, where the payload of each page is a flat text sequence with simple markup.
That depends on the wiki. The most well known - MediaWiki - uses traditional DB like MySQL or Postgres.
They still persist each page as a self-contained single flat text field, though. For the wiki model, it doesn't matter how it is stored in the hard drive, but that you get atomic nodes of content. If the node is a text file, you get the benefit of accessing such content through the file system and a text editor instead of a DBMS. That's invaluable for accessing content from a collection of multiple devices, operating systems and alternative applications, i.e. the use case for personal information.
> And your app does not know files changed so it can't selectively update the indexes/metadata.
Why would the app not know that files are changed? Any development environment nowadays may check for touched files and re-parses them on the fly, for example for instant preview of web pages.
> Why would the app not know that files are changed? Any development environment nowadays may check for touched files and re-parses them on the fly, for example for instant preview of web pages.
Modern OS provide APIs to watch file changes (on Linux e.g. it's inotify). However:
1) Does not work when your app is not running. When your app starts up it needs to rescan all files.
2) Does not scale well - watching files is expensive and OS usually have usage limits.
IDEs provide a great example since they need to solve essentially the same problem - when my Intellij starts up it spends a while until it scans all the changed files (to do that it must go through all of them). After that it starts complaining that my inotify OS limit is too low and it can't watch all the files in the project.
All this is fine for lightweight use. But if you're serious with using your knowledge base, you'll run into tens of thousands of items in the course of few years.
Wikis work that way, where the payload of each page is a flat text sequence with simple markup.
The structure, relations and metadata could then be stored in a serverless database, like Git does in the .git folder. Not perfect, but I think the benefits for personal information outweight the limitations.