[
https://issues.apache.org/jira/browse/COMPRESS-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324225#comment-17324225
]
Peter Lee commented on COMPRESS-574:
------------------------------------
I see. Thank you for your detailed information.
> _File.createTempFile how do you size the temporary directory ?_
We can avoid creating a file, by creating the zip in memory. You can see
_ZipTestCase.testZipArchiveCreationInMemory_ for detailed implemention.
> _Also a third problem I did not mention is the time before the client receive
>the first byte, we wait for the ZIP creation to be complete before creating
>the ZipIS._
With _closeArchiveEntry()_ called, the LFH and entry data would have been
written to the target file or byte array. I think the raw data can be
transported then, and it's happened before the Zip is finished.
> _Recently download servers got overloaded, so I look again and still found
> nothing. So I decided to look at the ZIP spec directly to check if it was
> possible to stream. And it was, so I implemented it. I give the code here, so
> someone like myself in the future will find it._
Thank you so much once again! And I'd like to hear others about your patch.
> Byte range support in archive creation
> --------------------------------------
>
> Key: COMPRESS-574
> URL: https://issues.apache.org/jira/browse/COMPRESS-574
> Project: Commons Compress
> Issue Type: Improvement
> Components: Archivers
> Reporter: Gaël Lalire
> Priority: Minor
> Attachments: DynamicZip.java, DynamicZipTest.java
>
>
> When you have a ZIP which contains _N_ components and you want to let the
> user choose which components it needs, you need to create _2^N - 1_ ZIP.
> So the idea is to store each component once (or twice if you want both
> deflated and stored version), and create the ZIP on the fly.
> For the moment you can stream with a ZipOutputStream but if you need an
> InputStream things get a lot harder. I guess programs are writing the ZIP to
> a file system and read from it after, so not really a streaming anymore.
> Also ZipOutputStream will never allow you to resume from a byte range, you
> need to generate all previous data.
> So I made a class to do that, I think such functionality has its place in
> commons compress.
> You can see my code attached and adapt it for better integration / other
> archive type support or simply to get inspired.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
