Zipped XML. Welcome to 1999 designs

ACCount37 an hour ago | parent | next [-]

Let's be honest, the real 1999 design would have been a custom binary format that happens to use the endian of the system it was developed on, and leaks bits and pieces of unflushed memory buffers whenever it writes to disk.

	▲	flohofwoe an hour ago \| parent [-]
		No that would be an early 1990s file format ;) 1999 is exactly right for the start of the XML hype, everything had to be XML, it would single handedly solve the software crisis (after OOP failed to do that) because everything would be able to talk to everything!

▲

muhehe an hour ago | parent | prev | next [-]

What would you consider good modern design?

▲

supriyo-biswas an hour ago | parent | next [-]

SQLar[1], see [2] for some reasoning around why a database is preferred over zipped XML. Though, I'd be fine with a DBM-style database too as we only need the key-value part of it.

[1] https://sqlite.org/sqlar/doc/trunk/README.md

[2] https://www.sqlite.org/affcase1.html

▲

chungy an hour ago | parent | next [-]

the SQLite archive format (it's probably worth linking to the main documentation[1], instead of the very old experimental repository) may not really be a good fit for something like GIMP's native file format. (To be clear, "SQLite archives" are not special compared to any other database: it's just a well-defined schema for an sqlar table, which the sqlite3 command line tool is able to create, update, and extract using syntax like the tar command.)

That being said, SQLite would still be a good choice, especially as it's a format that's really intended to be modified in-place, and has good data integrity features (eg: keep WAL enabled so that mid-save crashes/shutdowns don't corrupt your file), neither of which are provided by Zip. You could even just run zlib on data (be it XML or what have you) if optimizing the on-disk size of the file is desirable.

[1] https://sqlite.org/cli.html#sqlite_archive_support

▲

flohofwoe an hour ago | parent | prev [-]

The problem with using database blobs for load/save is that you usually need a full database client in the application. SQlite advertises that use case, but it is complete overkill. You never need to run any sort of complex SQL query on an image file format for instance. Using XML+ZIP in this day and age is also a strange decision, but at least that way the data is inspectable with unzip, a text editor and an image viewer (assuming they use a standard image format to store the raw pixel data).

▲

TeMPOraL 43 minutes ago | parent [-]

> You never need to run any sort of complex SQL query on an image file format for instance.

Sure you will. Plenty of features that don't exist, or are implemented badly, because you can't easily do it.

Quick mental translation table: if you think "iterate over every ..." or a `for` loop, that's your SELECT query. If you think about `if` conditions, that's the parts that go after FROM clause.

	▲	zelphirkalt 6 minutes ago \| parent \| next [-]
		SQLite is fast, but it won't be faster than a hot loop in C. Having the loop construct dictated by the file format seems bad. For images it seems more reasonable to have them in-memory, except for huge image edge cases.
	▲	x3ro 36 minutes ago \| parent \| prev [-]
		In order to have any advantage from this, you would have the added complexity of splitting your file format into tables that can be queried in a useful manner. However, for an image file format, you most likely need to hold the entire definition in memory at all times anyway. Assuming that’s the case, doesn’t XPath get you there most of the way (assuming XML), with _way_ less complexity?

▲

speedgoose 35 minutes ago | parent | prev [-]

Compressed JSON with the binary content encoded in base64 strings, obviously.

▲

einpoklum 16 minutes ago | parent [-]

Why would zipped JSON be fundamentally superior to zipped XML?

	▲	speedgoose 2 minutes ago \| parent [-]
		To answer seriously, my parent comment is a joke, JSON is a simpler format that maps better to most programming languages internal memory representations. Developers tend to prefer JSON’s simplicity over XML.

▲

elric an hour ago | parent | prev [-]

Welcome to 2026 unfounded hot takes.

Or less snarky: what's your gripe with zipped XML? It compresses reasonably well, has a useful structure, and has decades of mature tooling around it.

	▲	OskarS a few seconds ago \| parent \| next [-]
		The obvious alternative is SQLite, and it has many advantages. If you want to do a "zipped list of files", SQLite does that just fine (that's what SQLar is), but it can do so much richer data. Even if you don't want that, it still offers resiliency that "zipped XML" can't match: if your software or computer crashes in the middle of saving your file, it'll almost certainly corrupt it. With SQLite, not an issue: all transactions are atomic, they either happen entirely or not at all. I don't know what "mature tooling" you're talking about for zipped XML, but I guarantee you it's not going to be better (or more mature) than SQLite and its ecosystem.
	▲	x3ro 38 minutes ago \| parent \| prev [-]
		Thanks! I had the exact same question for various of these posts here. I know these may be different groups of people, but I always see people advocating for simplicity, and zipped-XML is as simple as it gets, needs barely any extra dependencies (none in GIMP I assume), and is proven to work well (Word etc). I also don’t understand why SQLite would be preferable here, considering you will likely also store large binary files alongside your document definition.. What does a db engine give me here?