This suggestion seems similar to Digg&#39;s Stream project that uses multipart documents: <a href="http://github.com/digg/stream">http://github.com/digg/stream</a><br><br><div>While it would be nice to have a way to parse and handle this in JavaScript, it shouldn&#39;t be JavaScript&#39;s responsibility to work with large object data and duplicating it as in-memory data strings.</div>
<div><br></div><div>The real issue here is the overhead of each additional HTTP request for those thousands of objects. But that&#39;s useful for all parts of the spec if you can download it as a single package even without JavaScript. Images, CSS, background-images, JavaScript, etc. Currently you can include graphics as data URLs in CSS. Using a package you could package whole widgets (or apps) as a single request.</div>
<div><br></div><div>I&#39;d suggest that this belongs in a lower level API such as the URIs and network stack for the tags. You could specify a file within an archive by adding an hash with the filename to the URI:</div><div>
<br></div><div>&lt;img src=&quot;<a href="http://someplace.com/somearchive.tgz#myimage.jpg">http://someplace.com/somearchive.tgz#myimage.jpg</a>&quot; /&gt;</div><div><br></div><div>&lt;style type=&quot;text/css&quot;&gt;</div>
<div>#id { background-image: url(<a href="http://someplace.com/somearchive.tgz#mybackgroundimage.jpg">http://someplace.com/somearchive.tgz#mybackgroundimage.jpg</a>); }</div><div>&lt;/style&gt;</div><div><br></div><div>&lt;script src=&quot;<a href="http://someplace.com/somearchive.tgz#myscript.js">http://someplace.com/somearchive.tgz#myscript.js</a>&quot; type=&quot;text/javascript&quot;&gt;&lt;/script&gt;</div>
<div><br></div><div>var img = new Image();</div><div>img.src = &quot;<a href="http://someplace.com/somearchive.tgz#myimage.png">http://someplace.com/somearchive.tgz#myimage.png</a>&quot;;</div><div><br></div><div>Now which packaging format to use would be a discussion on it&#39;s own. An easy route would be to use multipart/mixed that is already used for this in e-mails and can also be gzipped using Content-Encoding.</div>
<div><br></div><div><div class="gmail_quote">On Thu, Jul 30, 2009 at 11:41 AM, Anne van Kesteren <span dir="ltr">&lt;<a href="mailto:annevk@opera.com">annevk@opera.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, 30 Jul 2009 08:49:12 +0200, Gregg Tavares &lt;<a href="mailto:gman@google.com">gman@google.com</a>&gt; wrote:<br>
&gt; What are people&#39;s feelings on adding a Binary Archive API to HTML5?<br>
<br>
</div>I think it makes more sense to build functionality like this on top of the File API rather than add more things into HTML5.<br>
<div class="im"><br>
<br>
&gt; It seems like it would be useful if there was browser API that let you<br>
&gt; download something like gzipped tar files.<br>
<br>
</div>We already have that: XMLHttpRequest.<br>
<div class="im"><br>
<br>
&gt; The API would look something like<br>
&gt;<br>
&gt; var request = createArchiveRequest();<br>
&gt; request.open(&quot;GET&quot;, &quot;<a href="http://someplace.com/somearchive.tgz" target="_blank">http://someplace.com/somearchive.tgz</a>&quot;);<br>
&gt; request.onfileavailable = doSomethingWithEachFileAsItArrives;<br>
&gt; request.send();<br>
<br>
</div>I don&#39;t think we should introduce a new HTTP API.<br>
<div class="im"><br>
<br>
&gt; function doSomethingWithEachFileAsItArrives(binaryBlob) {<br>
&gt;   // Load every image in archive<br>
&gt;   if (binaryBlob.url.substr(-3) == &quot;.jpg&quot;) {<br>
&gt;      var image = new Image();<br>
&gt;      image.src = binaryBlob.toDataURL();  // or something;<br>
&gt;      ...<br>
&gt;   }<br>
&gt;   // Look for a specific text file<br>
&gt;   else if (binaryBlog.url === &quot;myspecial.txt&quot;) {<br>
&gt;     // getText only works if binaryBlob is valid utf-8 text.<br>
&gt;     var text = binaryBlob.getText();<br>
&gt;     document.getElementById(&quot;content&quot;).innerHTML = text;<br>
&gt;   }<br>
&gt; }<br>
<br>
</div>Having dedicated support for a subset of archiving formats in within the API for File objects makes sense to me. Latest draft of the File API I know of is<br>
<br>
  <a href="http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml" target="_blank">http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml</a><br>
<br>
and the mailing list would be <a href="mailto:public-webapps@w3.org">public-webapps@w3.org</a>.<br>
<font color="#888888"><br>
<br>
--<br>
Anne van Kesteren<br>
<a href="http://annevankesteren.nl/" target="_blank">http://annevankesteren.nl/</a><br>
</font></blockquote></div><br></div>