From: Robert Feldt <feldt@...>
Date: 2002-01-27T19:08:20+09:00
Subject: Re: [ANN] rubyzip 0.3.1

On Sun, 27 Jan 2002, Thomas Hurst wrote:

> * 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?
> 
Oops, I meant Archive::Tar.new(entries).to_s or something like that but
your scheme is probably better. I agree that a higher level API should add
convenience functions so that it maximally smart and forgiving
(Archive.open ...).

> This is why I want a higher level API, so instead you do;
> 
As a layer on top of the basic classes thats great since it'll catch the
common cases. Basing it on a "combinator" style design is good though
since I might want to use my own compressors or what have you. But you
already know all this so I'll shut up now... ;-)

BTW, I'd like to adapt the LZO compressor in CompressionR to your
API. Will there be general Writer and Reader mixins so that it
suffices to plug-in a compression alg (though some algs need the
whole lot before compiling)? Looking forward to a release.

> Archive::Tar.open('foo.tgz', 'w')
> 
Making it possible to register "handlers" with Archive might be to take
things to far, or? 

Archive.register_file_handler("tgz", "tar.gz", [Tar, Zlib])

and there is Tar.writer, Tar.reader, Zlib.writer, Zlib.reader and for
writing its the given order (Zlib is inner and Tar outer) while for
reading its the reversed order.

Adds some modularity but might be overkill...

Cheers,

Robert