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 <[EMAIL PROTECTED]> 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] http://grobmeier.de/commons-compress-draft-2.zip -- Sandy McArthur "He who dares not offend cannot be honest." - Thomas Paine --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
