DACT has very rich network support.  It supports referencing files on the command line (though not in the way you would expect), embedding netscape-style URLs in the header to be checked (and CRC verified) before extracting the local data, and even emebedding a file with a list of URLs to check with variable substitution.

Support for extracting files on the command line currently operates exactly the same for local files as for files specified in URL style.  This means that if you were to do:<br>
&nbsp;&nbsp;&nbsp;&nbsp;<tt>dact -d
DACT would try to write to the file which will fail.

Examples:
<ul>
  <li><tt>dact -Hu report.ps</tt><br>This would create the file report.ps.dct which contained no actual data, but rather the two CRCs and a reference to the online version of report.ps.dct. This is useful where you want to include a large file in a distribution but don't think most people will ever use it.</li>
  <li><tt>dact -nu bobsoft-latest.tar</tt><br>This would create a file called bobsoft-latest.tar.dct that contained the compressed contents of bobsoft-latest.tar and a reference to but no CRCs. This is useful when you want to distribute something labled "latest" and be accurate. Upon decompression DACT will first check the URL for the file, if that fails, use the actual contents. The CRCs are left off to allow the online version to be different (since supposedly it will be changing.)</li>
  <li><tt>dact -dc | tar -xf -</tt><br>This is useful for decompressing files from the internet without storing their compressed forms on disk.</li>
  <li><tt>dact -nu bobsoft-bin</tt><br>This is useful for providing a precompiled binary, because of the substitution done, the correct binary will be fetched when attempting to decompress the created file bobsoft-bin.dct (which could contain a shell script telling the user there was no available precompiled binary, since it would default to the local file only if the network URL was unavailable.)</li>
</ul>