Yup; I'm taking care of the duplication in trunk on my github fork. The other interesting branch to look at is the somewhat stale "concurrentSupport" branch and in particular the class ConcurrentZipCreator. This is my primary goal, I just went off on a round of yak-shaving first. I seem to have finished with the yaks now, so I aim to rebase this branch to trunk soon.
I suppose I will be committing the "ConcurrentZipCreator" to c-compress. Originally I had this in plexus-archiver, but I moved it over once the use case was sufficiently well understood. So right now I have no code in plexus-archiver, other than a branch or two with early versions of ConcurrentZipCreator in it. Right now the problem of multiple algorithms is not "my" itch; I have enough other itches right now. My todo list right now look like this: A) Think about manifest handling in genreal B) Investigate manifest merging in ConcurrentZipCreator. ATM I'm just thinking of exposing all the added manifests as a collection and leaving this to the client to merge stuff when multiple manfests are present. C) Decide on the ultimate thread-safety issues in the client front-end (ConcurrentZipCreator). I'm walking the line right now (quite a risky model), and I'd like to make it clearer. 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. I suppose that about sums it up. When these things are done I'm ready :) Kristian 2014-12-26 18:54 GMT+01:00 Stefan Bodewig <bode...@apache.org>: > On 2014-12-23, Stefan Bodewig wrote: > >> Your commit message calls out writeOut as a particilar problem. >> Fortunately this is one is final, so we don't have to retain the effect >> of subclasses overriding it. Wouldn't it be possible to have writeOut >> call the StreamCompressor's writeOut method so it still worked as >> before? > > I see you've already started to implement that in your github fork. :-) > >> [As an aside I'd prefer the StreamCompressor being passed into the >> stream so we don't need subclasses just to replace the compressor.] > > At least for the ScatterZipOutputStream I've started to experiment a > little: > <https://github.com/bodewig/commons-compress/compare/scatter-backing-store> > > As for > >> One problem of the zip package is that it doesn't support all the >> other compression methods possible for ZIPs, this might be a possible >> extension point. > > I'd like to see where you are going to take the compressor before I try > to dive in. Do I need to look at your plexus-archiver fork? > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
