On 08/09/14 05:35, Richard Hipp wrote: > See the essay at: > > http://www.sqlite.org/affcase1.html > > Comments, criticism, and feedback are welcomed.
BTW historically Microsoft used a "file system" for Office files before the XML stuff (ie even in the first versions from over 20 years ago). Back then the file system was a variant of FAT. The underlying format of the files was also optimised for modifications, recording things as a series of chunks rather than as contiguous content. The reason I mention all this is because the obvious solution for an XML world is to do the ZIP file approach allowing much compatibility for existing code and formats, not because it is the best solution out there. "Incremental update is hard" That isn't strictly true. ZIP files (unlike the majority of formats) store the central directory of content at the end of the file. You can update a zip file by appending the updated content, and then appending the new central directory but with the file name pointing to the updated content not the older version. That does then require some form of garbage collection, but space is way larger these days. It also seems possible to leave space after a file before the next one as room to grow thereby not needing a full rewrite on small changes. As to SQLite, I think the biggest issue is dealing with corrupted content. A zip file has a file as a unit of content with each one separately compressed and checksummed. If you corrupted a random byte of a zip file you could easily determine that it has happened and isolate which file is affected. You may even be able to recover from it (eg it was a small picture). SQLite has no way of finding corrupted content nor isolating it. The integrity check pragma might find something if the corruption happened somewhere in metadata, but other than that you are unlikely to discover it. Previous riding of that high horse (rejected): http://www.sqlite.org/src/tktview?name=72b01a982a Zip also has encryption as standard which SQLite doesn't. Overall I'd suggest keeping most of the content but changing the focus to "Best practises when using SQLite as an application file format". ie if someone is sold on SQLite as the format then what should they do. As an example I have found that versioning and undo/redo are the most important things to get right up front. Showing the triggers to use for undo/redo would be helpful. Suggesting a thumbnail entry is good too, etc. Roger _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
