commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sandy McArthur" <>
Subject Re: [compress] Introducing the Compress-Interface
Date Tue, 07 Mar 2006 17:59:15 GMT
First, I don't think a compress project does much new. VFS already
seems to provide read-only access to common archive types. The JDK
comes with read-write support for Zip and Gzip files. And Ant has
read-write support for Zip, Tar, Gzip, Bzip2 and maybe others.

If you're going to start a new project I think you should plan big and
long term. I'd call it [archiver] or something and anticipate support
for the basics: .zip and .tar (tgz and tbz2) and plan for possibly
supporting other archive formats such as .iso, whatever DVD's use,
Microsoft's .cab, .dmg (the Apple disk image), .rar, and obscure
archive formats like raw filesystem images (think mount over the
loopback in unix).

Different formats support different features. Not all allow you to
update an existing archive (zip) and some only allow it a few times
(.iso can be updated no more than 4 times). .dmg files can be updated
so long as it doesn't grow the pre-allocated file.

To support all these formats with a mostly unified interface would
require a two step process.

To create an archive:
1. create a set of files and their dir structure that you will want
into an archive.
2. generate the archive with the contents of that file set.

To read an archive:
1. figure out what type of archive a file or input stream is (possible
autodetect somehow) and create an archive object instance
2. Grab the file set from the archive so you can then get input
streams of each file

If you have a file set you should be able to:
* Pass it to another archive object which can be used to convert from
one type to another.
* Query if the file set is backed by a updateable archive type and
what operations it supports. Then after you've made changes call a
saveChanges method.

I'd also plan for making the implementations pluggable and
discoverable with the service discovery feature introduced in Java
1.2, I think.

On 3/7/06, C. Grobmeier <> wrote:
> after thinking a lot about the difference of archivers and compressors,
> i am not sure how to proceed with it.
> At the moment [1], we have an Archiv Interface. This fits fine for Tar
> and Zip. If we imagine gunzip or bzip2 as an archive for an single file,
> we would be fine aswell.
> For the compression portion, we could have an Archiv::setCompression(
> new TarCompressor()); method. For Zip we could have
> Archiv::setCompression( new ZipCompressor());
> (just an example, we will not have static methods here!)
> We could implement a default Compressor for every Component, for
> example, ZipArchiver would have ZipCompressor as a default, so it's not
> a must to care about it.
> A compressor could be used standalone. In case of bzip2 it would be not
> problem, but how would a zipcompressor act? Archiving simply in zipformat?
> Having said this i am afraid my thoughts could make everything to
> complex. On the other hand, this sounds like a good idea for [compress].
> Every comment on this important question is welcome.
> Regards,
> Chris
> [1]

Sandy McArthur

"He who dares not offend cannot be honest."
- Thomas Paine

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

View raw message