Using a SQLite database for Session Restore seems to make sense. However, it would make it even more difficult to get data out of it when necessary. As ugly a

Using a SQLite database for Session Restore seems to make sense. However, it would make it even more difficult to get data out of it when necessary. As ugly as a mess of JSON is, at least it's text, and I don't have to write a SQL query to grep for URLs. Why not just use the filesystem? Imagine a layout like this: + profilename.default |--+ sessionrestore |--+ <timestamp> |--+ window1 | |--+ tab1 | | |--- cookies | | |--- formdata | | |--- title | | |--- url | ---+ tab2 | |--- cookies | |--- formdata | |--- title | |--- url ---+ window2 |--+ tab1 | |--- cookies | |--- formdata | |--- title | |--- url ---+ tab2 |--- cookies |--- formdata |--- title |--- url One directory per timestamp, containing one directory per window, containing one directory per tab, containing one file per data type. All plain-text. Change a tab, just write to that tab's files, and update the timestamp directory name. Every x minutes, make a new timestamp tree, keeping y old ones as backups. No serializing and writing entire sessions to disk at once. Only small writes to small files. All plain-text, easy to read outside of the browser. Easy to copy, backup, modify, troubleshoot. No complex JSON, serializing, or database code. Use the write-to-temp-file-then-rename-over-existing-files paradigm to get atomic updates. Need to know if part of a session on disk is stale? Check the mtime for that file, see if it's older than the last time that data was changed in memory. Simple stuff. Straightforward. No overengineering. No bloat. Why not do this?