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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
