4 ms·
About 1, directory of files, many formats these days are just a bunch of files in a ZIP. One thing most applications lack unfortunately is a way to instead just
by 3036e4 1y ago
About 1, directory of files, many formats these days are just a bunch of files in a ZIP. One thing most applications lack unfortunately is a way to instead just read and write the part files from/to a directory. For one thing it makes it much better for version control, but also just easier to access in general when experimenting. I don't understand why this is not more common, since as a developer it is much more fun to debug things when each thing is its own file rather than an entry in an archive. Most times it is also trivial to support both, since any API for accessing directory entries will be close to 1:1 to an API for accessing ZIP entries anyway.
When editing a file locally I would prefer to just have it split up in a directory 99% of the time, only exporting to a ZIP to publish it.
Of course it is trivial to write wrapper scripts to keep zipping and unzipping files, and I have done that, but it does feel a bit hacky and should be an unnecessary extra step.
- strogonoff 1y agoYes, the zipped version is number four. It’s not great for the reason you noted. Some people come up with smudge/clean filters that handle the (de)compression, letting Git store the more structured version of the data even though your working directory contains the compressed files your software can read and write—but I don’t know how portable these things are. I agree with you in general, and it is also why my number one example is that you might not need a single-file format at all. macOS app bundles is a great example of this approach in the wild. One question I was hoping to ask anyone who thought about these matters: what accepted approaches do exist out there when it comes to documenting/speccing out file formats? Ideally, including the cases where the “file” is in fact a directory with a specific layout.