[
https://issues.apache.org/jira/browse/COMPRESS-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324198#comment-17324198
]
Gaël Lalire commented on COMPRESS-574:
--------------------------------------
Your first point is partially true, but it is true with what I said before.
However instead of considering the ZIP as the initial data, you can take an
entity on which you attach files instead.
For example the entity is an house.
The house as a lot of images and video. If you want all data of the house you
will get the full ZIP. If you want only images of the kitchen you will get a
part of the full ZIP.
Your second point is the byte range, it is useful to resume a download in user
browser. When you have a poor network it is your only way to get to the end of
a big download.
I mentioned AWS to give you a concrete example, but no this evolution can work
with any storage. You just need to get an InputStream from the storage
(_FileIS_, _FTPIS_, _S3IS_ ...) and give it to an implementation of
_DynamicZip.FileMeta_ like in _DynamicZipTest.TestFileMeta_.
> 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)
