Possibly zip size for no compression

[ghost]

I am not sure if this a valid or useful feature, but consider adding a function that will compute zip size for a set of entries, when level zero compression is used. Feel free to close if you don't see it as part of this library.

[dylex]

Since the original version already had this function (as you're probably aware) it should be possible, though it made a lot of assumptions about the format, z64, etc. I'll take a look to remind myself but certainly could be useful more generally in some cases.

[ghost]

Actually, I am leaning towards trying to use this for now - mrkkrp/zip#20 (comment) - as I can ask the file handle for its size. Computationally, that branch (mrkkrp/zip#22) of the zip library might take twice as long as your implementation to produce and serve a zip file, but the blind archive approach sounds interesting and might be able to generalize to computing sizes for compression level >= 1

I will close this issue for now, and reopen if I am actively using zip-stream again.

[ghost]

Download initiates faster with your approach than using disconnected file handles. Consider trying to converge this library with "zip" where enabling this behavior would be selected by users who need more sophisticated streaming instead of generating a file. Maybe a ZipArchiveStream monad with a subset of operations from the ZipArchive monad

[ghost]

https://en.wikipedia.org/wiki/Chunked_transfer_encoding - I haven't had time to experiment, but if you or I get around to it at some point, using that approach might get around the bug I was experiencing on OS X where the OS X zip utility manager was choking on the downloaded file when the content-length header was not sent.