AFAIK, no one has done this, at least not in this specific way, I have a need for it, and I can see it being used everywhere. So I'm proposing it, and I'm going to implement it.

My idea: The virtual tarball. (Or something?) A file extension of something like .vtb, or .mrr (mirror file). Inside, it looks like it's just an XML file with XHTML-renderable hyperlinks, but the file type is used by an executable that pulls the files down into the specified directory with the <a> tags' text as the save-to file name.

Example contents:

<ul class="mrr">
 <li class="mrrfile">
  <a
 href="http://cachefile.net/file_a.bin">file_a.bin</a>
 </li>
 <li class="mrrfile">
  <a
 href="http://cachefile.net/file_b.bin">file_b.bin</a>
 </li>
 <li class="mrrdir">dir1</li>
 <li class="mrrfile">
  <a
 href="http://cachefile.net/dir1/file_c.bin">dir1/file_c.bin</a>
 </li>
 <li class="mrrfile-alternate">
  <a
 href="http://otherurl.net/dir1/file_c.bin">dir1/file_c.bin</a>
 </li>
</ul>

Given this sample, here's what Visual Studio outputted as an XML Schema file from automatic conversion:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified"
 elementFormDefault="qualified"
 xmlns:xs="http://www.w3.org/2001/XMLSchema">
 <xs:element name="ul">
  <xs:complexType>
   <xs:sequence>
    <xs:element maxOccurs="unbounded" name="li">
     <xs:complexType mixed="true">
      <xs:sequence minOccurs="0">
       <xs:element name="a">
        <xs:complexType>
         <xs:simpleContent>
          <xs:extension base="xs:string">
           <xs:attribute name="href"
             type="xs:string" use="required" />
          </xs:extension>
         </xs:simpleContent>
        </xs:complexType>
       </xs:element>
      </xs:sequence>
      <xs:attribute name="class" type="xs:string" use="required" />
     </xs:complexType>
    </xs:element>
   </xs:sequence>
   <xs:attribute name="class" type="xs:string" use="required" />
  </xs:complexType>
 </xs:element>
</xs:schema>

The point of this is that it would look like HTML but it could be processed like a .zip file. Only difference between a .mrr file and a .zip file, other than the fact that a .zip file is compressed and isn't human-readable when introspected, is that a .zip contains the contents, whereas a .mrr file only contains hyperlinks to the downloadable files. In the above example, I also have an "-alternate" class so that the processor can see that as a mirrored repository for the same file.

Oh, and yeah, the point of the XHTML compatibility is partly for inspection and previewing, but also for Javascript DOM support. I'm thinking this could be my "engine" for a web browser script library pre-loader page idea I have for adding as a new feature for cachefile.net.

I'm going to get to work on an open source C# console application for Windows, as well as a Javascript browser caching implementation.

Update: I've spent most of the night prototyping the C# app. I'm calling it Mrrki ("murky"), and settled on .mrr (for "mirror"). Here's my first rough draft build: http://www.jondavis.net/codeprojects/Mrrki/0.1/Mrrki.zip.