[ 
https://issues.apache.org/jira/browse/COMPRESS-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324467#comment-17324467
 ] 

Gaël Lalire commented on COMPRESS-574:
--------------------------------------

_> We can avoid creating a file, by creating the zip in memory_

Yes but I mentioned in the description that _if you need an InputStream things 
get a lot harder_. I did not enter in the details, maybe you can get it to work 
with PipedIS & PipedOS or your own rolling buffer at the cost of one additional 
thread. Anyway I did not go that way because of very poor resuming (byte range) 
behavior of this solution.

> _With closeArchiveEntry() called ..._

 

Yes with the hard solution before, this problem is solved. Again byte range 
support is poor hence my ticket name.

 

 

> 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)

Reply via email to