It'd be better if they didn't require knowing the paths a priori. One of the fundamental strengths of ZIP is that the file list is at the end of the archive rather than the beginning, letting you dynamically discover and send contents in a streaming fashion. Forcing the list of files to be known a priori works against that.
Please test your library with the c10-archive test suite <a href="https://www.ee.oulu.fi/research/ouspg/PROTOS_Test-Suite_c10-archive" rel="nofollow">https://www.ee.oulu.fi/research/ouspg/PROTOS_Test-Suite_c10-...</a>
I did something similar to stream large amounts of data off of an embedded device via a zip file, falcon, and wsgi server with no external dependencies for actual zip stream.<p>Proof of concept: <a href="https://gist.github.com/1e22bbf31b7e5ae84bbdfa32c68e03a9" rel="nofollow">https://gist.github.com/1e22bbf31b7e5ae84bbdfa32c68e03a9</a>
I remember needing this 5+ years ago, I used a branch of a fork of python-zipstream <a href="https://github.com/longaccess/python-zipstream/tree/streaminput" rel="nofollow">https://github.com/longaccess/python-zipstream/tree/streamin...</a>
Yeah, I looked into this a while ago forgenerating photo gallery zip files on the fly. Currently I'm using lazygal to generate static html galleries and if I want to give users the option to easoly download the full gallery, it basically doubles the size I need to store, as lazygal simply creates a zip file and puts it next to the photos and html files in the static gallery folder it generates.<p>So I looked to creating the zip files on the fly when requested & streaming them to the client onthe other end withou having to create temporary files and/or a lot of memmory consumption on the server. I got it working on a prototype and even found some articles from others that got it working - it is not that hard, really.
The zip file format itself, and the compression algorithms, like deflate...all seem set up to encourage low memory usage. The directory, for example, is at the end of the file.<p>Also, most places in a zipfile you might not have context to write in a streaming fashion are predictable in size/position so you can throw in a placeholder and seek() back to it later.<p>Kind of a shame someone has to specifically implement a low memory usage library. That implies other implementations went the lazy route.
I wrote a servlet that streamed gigabytes of zipped data to HTTP clients in 2005. Something like this was baked into the JDK awhile ago. Why is it an achievement for Python, though?
I wish windows supported more than just zip natively. I would love something like a tar. So much easier to generate on the fly than compressed formats.