3 ms·

>or reconstruct the database from a dump. Indeed - just write a new file you export data to be shared with someone else. Heck, for many use cases (e.g. config

>or reconstruct the database from a dump. Indeed - just write a new file you export data to be shared with someone else. Heck, for many use cases (e.g. config files), the save_to_file() function can always start by deleting the old file completely, creating the DB from scratch, and filling it with data from memory (essentially, treating the DB files as immutable). Hardly a difficulty, no? And proprietary file formats aren't guaranteed to NOT have the problems you described; the only apriori advantage is that their structure is opaque. Hence my "security by obscurity" remark if my understanding is correct.

Const-me 8y ago
> just write a new file you export data to be shared with someone else. There's no good way to distinguish. Add separate File/Export command? Users will forget to use it. Add a checkbox on file dialog? Similarly, users will forget to check it. It's very unreliable. The only reliable way is treat every save as "export data to be shared with someone else". > proprietary file formats Very few left, the industry has moved towards open formats. For example, MS Word documents are zipped XMLs, ISO/IEC 29500.