On 2014-12-26, Kristian Rosenvold wrote: > 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.
Thanks. > Right now the problem of multiple algorithms is not "my" itch; I have > enough other itches right now. Understood. > My todo list right now look like this: > A) Think about manifest handling in genreal This applies to plexus since CC isn't doing any manifest handling at all right now. > 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. Since you see ConcurrentZipCreator coming to CC we should try to void special casing the manifest. ZipFile already has an API that exposes all entries of a given name, the same may be possible for ConcurrentZipCreator. > 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. May I ask sneaking in "prefer using delegation over inheritance where possible"? ;-) Cheers Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
