in reply to RFC: Archive::Tar::Streamed

Nice tricks. :-) It's not truly streaming in that it still keeps each archive member file in memory though. Nevertheless, in the common case that's going to be much better than keeping the entire archive in memory.

It might be more efficient to keep the same Archive::Tar object around, calling clear() on it when you're done with a stream chunk, instead of instantiating a new one at every step.

Makeshifts last the longest.

Replies are listed 'Best First'.
Re^2: RFC: Archive::Tar::Streamed
by rinceWind (Monsignor) on Jan 03, 2005 at 07:07 UTC
    Thanks for the comments.
    It's not truly streaming in that it still keeps each archive member file in memory though.
    That is not true for the output side. When writing a tar archive, I am passing a file name (or a list of file names) to A::T, but I suppose A::T could be slurping each file.

    On the input side, by presenting an Archive::Tar::File object (which contains the data for a file or directory, slurped) I am giving full flexibility to the application to decide what to do with it. It may be possible to provide a header only, and method calls to fetch the file straight to disk (I'll think about it, but my app doesn't need this right now).

    It might be more efficient to keep the same Archive::Tar object around, calling clear() on it when you're done with a stream chunk, instead of instantiating a new one at every step.
    I will certainly bear this in mind for the next version :).

    --
    I'm Not Just Another Perl Hacker

[reply]

      but I suppose A::T could be slurping each file.

      I think it does actually. Have a look yourself though, my review was somewhat superficial.

      ---
      demerphq

[reply]

In Section Meditations