From: Thomas Hurst <tom.hurst@...>
Date: 2002-01-28T00:46:20+09:00
Subject: Re: [ANN] rubyzip 0.3.1

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

> 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... ;-)

Don't overestimate my knowledge or experience, my background is in PHP
:)

> 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.

The reason I have Reader and Writer classes is that they're two very
distinct operations for tar, because it's rather ugly to do anything
randomly.  Updating typically involves uncompressing the entire archive,
stripping off the last 0-1k (depending on whether the archiver that made
it was broken, *grumble*), and appending the new stuff to the end,
something that's not really relevent to reading.

If you want to read an LZO compressed tar, you just get an IO-alike
object which deals with it and pass that in.

> > 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])

Archive would need to know about the bundled modules higher up the
hierachy by default, otherwise you end up loading all the handlers along
with Archive itself, which is Bad[tm].

Detecting tar involves a two-pass operation too; seeing if it's a g or
bzip file's easy enough, but to find out what's actually compressed
involves uncompressing and reading the first 512 bytes (to do it
properly, anyway).  I don't want to go the Windows way and depend on
file extensions, especially since these days browsers know about gzip
and tend to extract tarballs when you download them.

Something more along the lines of:

module Archive::Compress
        Archive.register(Archive::Compress, Regexp.new('^\037\235'))
end

May be more appropriate, then Archive recursively reads the top half-k
or so of the file, works out what it is, opens it through a filter, then
reads the first half-k of *that*.

While this isn't going to work for zip etc, where the compression is
internal to the format, it will let you read funny things like bzipped,
gzipped, compressed zips :)

> 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.

This is something like it, except Zlib wraps around IO objects; there's
no need for extending the API that way.  A stream compressor's way of
seeing the world is rather different from an archive's way of seeing it,
so I doubt they could be merged anyway.

> Adds some modularity but might be overkill...

Might be.  While tar pretends compression doesn't exist, zip and it's
relatives know about it intimately.

-- 
Thomas 'Freaky' Hurst  -  freaky@aagh.net  -  http://www.aagh.net/
-
Due to circumstances beyond your control,
you are master of your fate and captain of your soul.