Plamen Totev created COMPRESS-375:
-------------------------------------

             Summary: Allow the clients of ParallelScatterZipCreator to provide 
ZipArchiveEntryRequestSupplier
                 Key: COMPRESS-375
                 URL: https://issues.apache.org/jira/browse/COMPRESS-375
             Project: Commons Compress
          Issue Type: Improvement
          Components: Archivers
            Reporter: Plamen Totev


Currently clients of {{ParallelScatterZipCreator}} could provide 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} through 
{{ParallelScatterZipCreator#addArchiveEntry}}. From those two a 
{{ZipArchiveEntryRequest}} is created. Providing {{InputStreamSupplier}} solves 
the problem with opening too many files - streams are opened just-in-time - 
when an entry is  compressed, not when it's submitted.

But there are use cases when the stream may contain information about the 
{{ZipArchiveEntry}}. In those cases creating {{ZipArchiveEntry}} before the 
{{InputStream}} is opened won't work. If there is an option to supply both 
{{ZipArchiveEntry}} and {{InputStreamSupplier}} ({{ZipArchiveEntryRequest}}), 
this will solve the issue.

There is a bug in Plexus Archiver 
(https://github.com/codehaus-plexus/plexus-archiver/issues/53) that is example 
for such use case. Plexus Archiver have option that allows entries that are 
already zip files to be stored instead of compressed 
({{AbstractZipArchiver.recompressAddedZips}}). To detect if given entry is zip 
archive, {{AbstractZipArchiver}} should read the first several bytes of the 
stream. So creating {{ZipArchiveEntry}} before the stream is opened is not 
useful - the compress mode is not known. Opening the stream when the  
{{ZipArchiveEntry}} is created won't work either. Because you can add entries 
to {{ParallelScatterZipCreator}} a lot faster than you could compress them you 
could open too many files very fast. And I don't think opening and closing the 
stream is an option as such operations could be relatively expensive in the 
general case. But if it could supply both the {{ZipArchiveEntry}} and the 
{{InputStream}} just-in-time (by passing {{ZipArchiveEntryRequestSupplier}} to 
{{ParallelScatterZipCreator}}) then the problem is solved.

What do you think. Does the addition of 
{{ParallelScatterZipCreator#addArchiveEntry(ZipArchiveEntryRequestSupplier)}} 
make sense?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to