Le 23/12/2014 15:19, Kristian Rosenvold a écrit : > It depends :) > > All the commits I did so far represent distinct pieces of > functionality that someone could choose to use by itself, so if > c-compress was released tomorrow they'd be usable. That being said, > I'm still polishing the last high-level class that provides the > consumer-friendlier stuff to create a zip or a jar file. Even when I > do that, some of the underlying stuff will be visible. > > ScatterZipOutputStream is client extensible to provide different kinds > of backing store for the intermediate output. I might be able to hide > the StreamCompressor is part of the extensible type hierarchy for > ScatterZipOutputStream; I'll take a look. > > As you may have seen, there is one subclass > org.apache.commons.compress.archivers.zip.ScatterZipOutputStream.FileScatterOutputStream > that is implemented right now, which backs it straight to file. It is > possible for clients to make their own backing implementations of the > ScatterZipOutputStream. In my git repo I have 2 other implementations, > one using the commons-io DeferredOutputStream and another one using a > custom "OffloadingDeferredOutputstream", that basically offloads to > disk after N bytes but retains the stuff already written to memory. > (Deferred flushes *everything* to disk once it switches to > disk-based). Adding these two last implementations to commons-compress > would imply adding at least an optional dependency to commons-io, and > I have been deferring that question :) I can think of at least a 4th > implementation, which would use off-heap memory for storing stuff.
This sounds promising. I think a dependency on commons-io would be fine, and if you just use a couple of classes we may shade them inside the main jar to reduce the runtime dependencies. The OffloadingDeferredOutputstream class you describe looks like an interesting optimization for the DeferredOutputStream in commons-io, either as a new class or as an alternative operating mode. Regarding the commons-compress API, I guess most people will just use the default stores and not bother implementing one, so I'd rather close the API and hide the internal details. This gives us more freedom to refactor the code in the future. Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
