From: Thomas Hurst <tom.hurst@...>
Date: 2002-01-27T13:44:00+09:00
Subject: Re: [ANN] rubyzip 0.3.1

* Robert Feldt (feldt@ce.chalmers.se) wrote:

> Why as a string? IMHO, its better with
> 
>   archive = Archive::Tar.new(entries).compress(Bzip2)
> 
> or even
> 
>   archive = Bzip2.compress( Archive::Tar.new(entries) )

What are you passing around?  What's Archive::Tar going to return, the
entire tar archive as a string?

> where archives need not know about compressors at all => less
> coupling. But maybe they need to know about them anyhow to detect and
> correctly handle tgz as inputs...

All Archive::Tar knows is what a very basic IO object looks like.

So to make a compressed archive;

Archive::Tar::Writer.new(ZLib::GZipWriter.new(File.new('foo.tgz', 'w')))

Starting to look like Java.  Shall I throw in a few BufferedWriters for
good meassure? :)

This is why I want a higher level API, so instead you do;

Archive::Tar.open('foo.tgz', 'w')

And it works out compression scheme from the filename.  Similarly,
reading (gb)zipped archives can be done by reading the first half-k and
doing a pattern match to work out what it is.

There's even scope for;

Archive.open('some_archive')

And have it work out what type of archive it is and return the correct
type of object.  See how nicely the deep namespace works up in the
levels of abstraction? :)

And, of course, since we have a standard API;

Archive.extract('foo.zip', '/tmp/') do |message|
        puts "\r#{message}"
end
Archive.list('bar.tgz') do |entry| .. end

And so on can be done, and we can even change the entire Archive::*::
API and keep the basic methods the same, reducing the impact on anything
that uses it.

I'll try to get a prerelease out tomorrow so people can compare it with
rubyzip and comment on what a standard API should look like.

-- 
Thomas 'Freaky' Hurst  -  freaky@aagh.net  -  http://www.aagh.net/
-
Rascal, am I?  Take THAT!
		-- Errol Flynn