Discussion: support for non-seekable reading

[FauxFaux]

I would like to read entries from an un-seekable stream, such as stdin.

This pull request implements this by providing a read_single function that returns the next entry in the stream, or None if we've found the Central Directory, indicating the end of the file.

Not all of the metadata is available, as it's not all stored in the local header. This code involves a bit of copy-paste, but not as much as I was expecting. It would be nice to restructure ZipFileData such that it had the "core" entries (the ones that are available in the local header, as I'm partially exposing as ZipEntry), and the extended entries separately.

In terms of API.. uh. Java has ZipInputstream, which has an awful API. An archive could provide an iterator over entries, for non-seekable readers?

for (entry, reader) in streaming_archive.iter() { ..

I also don't know what to do about discrepancies between the Central Directory and what the iterator has already returned, when using this API. Perhaps the read_single entry could return the contents of the Central Directory when it's encountered, to allow users to work out whether they've seen deleted, or otherwise invalid entries? An iterator could validate this at the end, and Err() or something.

zip64 is a mess, but it's currently not supported by the other code.

[mvdnes]

Thank you for implementing this!
I am a bit busy at the moment, but will have a look at it soon. This would be a very nice feature to have.

[dherman]

@mvdnes I would love to use this functionality to be able to unpack a zip file as I'm reading it from a reqwest response. Is there any way I can help to get this feature implemented?

[mvdnes]

I have incorporated some of your code into this, and it seems to work for a few examples.
Currently the central directory is ignored. That could be an improvement. Sorry for the long time this took!
If you have any improvements or ideas, they would be very welcome.