From: "Thomas Søndergaard" <thomass@...>
Date: 2002-07-10T07:10:28+09:00
Subject: Re: SV: SV: [ANN] Archive 0.2

> On Wed, Jul 10, 2002 at 01:07:04AM +0900, Thomas S�ndergaard wrote:
> > Isn't this unnecessarily low level access - I don't see a need for
exposing
> > the raw header data. Also, I don't see a reason for treating the header
and
> > data parts as if they are somewhat similar (ie. parts). It seems like
> > "over-generalization"?
>
> Perhaps, but it has worked fine for me so far. :-)

It's not that I think it will cause problems other than it is unnecessarily
complex for users of the API. As the inventor you are not likely to have a
problem with it. :-)

> > > One nice thing of this design is that a mbox Entry can, for example,
> > > implement a to_zip method. [...]
> >
> > I don't see any reason that mbox Entry should now about zip archives
(to_zip
> > method implies some knowledge).
>
> I don't see a problem with it, I've always been happy with things like
> String#to_i or String#to_a.

I don't have a problem with String#to_i and String#to_a either, except I
don't like the naming, but that is a different issue ;-)

> > With a general archive interface it is
> > possible to do better, and write generic code for writing entries of one
> > archive to another regardless of the archive type.
>
> I have troubles figuring this.  Could you please post a pseudo code
> example?

I can try. This is what you wrote earlier:

quote = <<END_OF_QUOTE
in = File.open("/var/mail/joe")
out = File.open("/home/joe/mails.zip")

mbox = Archive::Reader::Mbox.new(in)
zip = Archive::Writer::Zip.new(out)

mbox.scan do |entry|
zip.add(entry)
end

The `add' method from Archive::Writer will see that we're trying to
write on a zip and that we have a Mbox::Entry#to_zip method, so will
use that, and we'll have converted from Mbox to Zip on the fly.
END_OF_QUOTE

I think this example is basically fine, except your comment about how
zip.add(anEntry) will recognize that Mbox::Entry has a to_zip method. This
should not be necessary because Entry is (or should be) an object that
implements an interface that is common for all archive entries.


>
> > > If you have any questions, just ask.
> > I don't understand the interface completely. When you iterate over the
items
> > in the archive, will you generate Entry objects that contain the full
> > uncompressed contents of the archive entry? That *might* be reasonable
for
> > mbox files but for zip and tar archives it seems unreasonable,
>
> It is in the to do list already.  The first incarnation of Archive
> (which I posted quite some time ago) had a preloading/caching scheme,
> but it was growing too complicate.  When I started rewriting it, I
> decided to shed it entirely and concentrate on the interface, and add
> loading schemes afterwards.  Plans included exposing entries as IO
> objects, handling via WeakRef those who were cached, and caching the
> `map' of the archive (even marshalling to disk, as Thomas Hurst
> suggested) so that it wouldn't have to be rescanned.

Ok. It seems to me that your design is heavily influenced by the structure
of tar.gz files, where the archive is compressed, instead of the archive
containing compressed entries (I think this is a short-coming in tar.gz
files). Are there other archive types that are as expensive to scan? What
other archives would benefit significantly from cached (to disk) maps of the
archive? Or from the iterative access, where you have to iterate over
entries, even if you know the id or name of a particular entry that has your
interest.

Thomas