I think you asked a very good question and are thinking along the right lines.

As counterpoint to other responses, I hate modules that insist on writing stuff to disk, and force me to re-open the output file* in order to get the data back into my program.

Maybe

• I only need a 1 of the 100,000 files in the archive.
• I don't have enough disk space to expand the whole archive and want to process the files one at a time.
• I want to change the names of the files before they are written.
• Or only write those that contain a given string.
• Or I want write 'head' and/ or 'tail' utilities to apply to the files inside the archive.
• Or I want to process a huge archive from an ftp stream and stop transferring when I find the file I want.
• I need to create the file with special permissions or security attributes, or on a different machine.
• Or...

So, I'd infinitely prefer an interface that allowed me to supply an open filehandle for the archive file (new or existing), and methods for adding and retrieving files from the archive:

Reading

use Your::Module;

open my $arc, 'ftp ftp://some.dot.com/pub/3GB.archive |'
    or die;
local $/ = \65536; ## Could your module handle this?

my $arcObj = Your::Module->new( $arc );

while( my( $name, $dataRef ) = $arcObj->next ) {
    if( $name =~ m[^file(\d+.type)$]
    and $$dataRef =~ m[this|that] 
    ){
        open $out, '>', localtime . $1 or die $!;
        print $out $$dataRef;
        last
    }
}
[download]

Writing

use Win32API::File qw[ :all ];
use Your::Module;

my $hObject = CreateFile( 
    '//?/UNC/Server/Share/Dir/File.Ext',
    FILE_READ_EA,
    FILE_SHARE_READ,
    pack( "L P i", 12, $pSecDesc, $bInheritHandle ),
    TRUNCATE_EXISTING,
    FILE_FLAG_SEQUENTIAL_SCAN|FILE_FLAG_WRITE_THROUGH,
    SECURITY_IDENTIFICATION|SECURITY_IMPERSONATION,
    0
) or die $^E;

OsFHandleOpen( FILE, $hObject, $sMode ) or die $^E;

my $arcObj = Your::Module->new( \*FILE );

opendir DIR, '//SERVER/DIR/';
while( my $file = readdir DIR ) {
    open my $fh, '<', $file or die $!;
    $arcObj->addFile( 
        "/DIR/$file", do{ local $/; <$fh> } 
    );
}
close DIR;
[download]

Providing that kind of flexibility for the users, combined with the reduction in code in your module, would make your module more powerful and useful.

Especially as you're providing 'arcit.pl' and 'unarcit.pl' scripts for the simple case, thereby avoiding the "boilerplate code" charge.

(*usually after patching the module to provide a way of finding out the filename)