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

Stefan Bodewig commented on COMPRESS-574:
-----------------------------------------

[~gaellalire] many thanks for your code. This is not really a patch to this 
library as such, you are providing a completely different API that doesn't use 
anything provided by Commons Compress internally. I've got a hard time 
envisioning how we'd integrate the two with each other.

Are you aware of {{ZipArchiveOutputStream}}'s {{addRawArchiveEntry}} method? 
Yes, I've read you want the final result as an {{InputStream}} without holding 
the archive in memory, but I must admit I don't understand why. The server 
use-case you are talking about could be writing to the ServletOutputStream (or 
something similar) directly.

Your requirements sound very specific and so far you are the first person I've 
heard of with exactly the constraints you describe.

> 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