commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
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
doesn't.

> 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

+1.

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
algorithm
> 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,
though.

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
issue?
>

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

Cheers,
Brett

[1]
http://cvs.codehaus.org/viewrep/plexus/trunk/plexus-components/plexus-archiver
[2]
http://cvs.codehaus.org/viewrep/plexus/trunk/plexus-components/plexus-archiver/src/main/java/org/codehaus/plexus/archiver/Archiver.java?r=2989
[3]
http://cvs.codehaus.org/viewrep/plexus/trunk/plexus-components/plexus-archiver/src/main/resources/META-INF/plexus/components.xml?r=2989

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message