2014-12-28 11:35 GMT+01:00 Stefan Bodewig <bode...@apache.org>: > On 2014-12-26, Kristian Rosenvold wrote: >> A) Think about manifest handling in genreal > > This applies to plexus since CC isn't doing any manifest handling at all > right now. Yes, I'm thinking along the lines of just making it "easy" for the client to do this task. I'll try to keep the manifest-specific stuff out of CC.
>> D) Look at performance in the "gather" phase. It's too slow right now, >> even with my last commit on trunk. Consider moving the creation of the >> LFH to the multithreaded parts and actually copy parts to the central >> directory upon merging. Ideally, the "gather" phase should be just IO. >> Maybe make the creation of the central directory a Deferred stream >> too, preferably of the offloading type. > > As long as you only write to the central directory stream after you've > completely written the entry (otherwise you may not know the sizes > depending on the method and whether the backing store is seekable) this > should be doable. The nice thing about using ScatterZipOutputStream first is that we know *everything* about sizes and crcs before we start writing the zip file. So the only thing we really need to know for the central directory is the offset, which is also known up-front as long as scatter is fully complete before gather. So at some point I'll also be looking at single-pass zip writing in ZipArchiveOutputStream (when using raw methods), but that's on the "nice to have"" list. > > May I ask sneaking in "prefer using delegation over inheritance where > possible"? ;-) OMG; I seem to have gone full circle on this. I have been deeply in the "prefer delegation" camp for the last 15 years or so. For the last year or so I have been exposed to "inheritance"-based extensions in @dayjob, and it's rubbing off on me.... Kristian --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
