commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: [compress] Discussing compress
Date Sun, 05 Mar 2006 03:02:36 GMT
Replying to a few of these things. Sorry for neglecting the thread so long.

C. Grobmeier wrote:
> I noticed, that compress ist divided into three different APIs, one for
> every compression algorithm: Zip, BZip2, Tar.

Tar isn't a compression algorithm.

I actually think commons-archiver is a better name (the library I have
used is plexus-archiver [1], which is derived from the same code and I
want to merge them here).

Note that there is also the unpack/decompress portion as well.

> Next problem is the lack of a commonly used interface: it seems one have
> to learn everything about the 3 components to use it. This is quite
> uncomfortable.

I totally agree. See [2]. Currently this focuses on just a single
creation task, not updating an existing one. I think this API can remain
though, and create() fails if it already existed, update() fails if it

> Here are the keypoints. Compress should be used to:
>     - load or create an existing compressed file,
>     - add files to compressed file,
>     - compress a file,
>     - return a list of stored files
>     - delete a single file from the compressed file
>     - in a later release: set special fields, like zip-fields


Piero Ottuzzi wrote:
> Hi Chris,
> I was thinking that something like
> Compress.getInstance(String compressorType);
> like Crypto would be nice.
> This way you can get a unique "entry point" for every compression
> that can provide its own methods to compress/decompress/add files etc etc.

I agree, but it should be an optional extra. Everything should be able
to be built from a bean with a public empty constructor so I can use
plexus to instantiate them (as you'll see from [3]). Other constructors
and factories are fine as long as they aren't required. BTW, if I use
factories, I usually instantiate them and they have a list of available
providers, then loop through and find ones based on requests, rather
than using the static getInstance( ... ) style because of this. I don't
know what others think of that.

> For this to work you need a configuration file, and later it might be
> fine to have something like Compress.getInstance(InputStream is).
> Often it is not possible to determine the compression based on the
> filename extension, you might have to look at the stream or its mime type.
> So I think this should be solved by a higher level api.
> Said that, I think this should be the part where commons-vfs comes in.
> It already provides a unique api to access a wide variety of
> filesystems/types.

I disagree, I think this would be useful in compress without vfs. I'm
thinking something like:

Archiver {
 boolean canReadFile( File )
 boolean canReadStream( InputStream )
 bollean canReadMimeType( String )

This might just check the extension, or might read the signature or mime
type. That would allow the factory I mentioned above to loop over them,
making plugging in new ones very easy.

Mario Ivankovits wrote:
> ... but be sure to
> only work with streams in your public API. So you might have to
> decompress and recompress the archive in a local temp folder to make
> those operations work.

I think this is the right way to start. I think investigating more
performant methods for large archives might be a good idea later too,

C. Grobmeier wrote:
> Sounds good to me.
> Having this in mind, i will try to write some simple files as a basis at
> the weekend.
> How do i proceed then? Sending it to this list? Creating an bugzilla

I don't recall seeing anything come in. Is this still happening? If not,
can we kick it off again?



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message