<br><br><div class="gmail_quote">On Tue, Aug 4, 2009 at 6:43 PM, Ian Hickson <span dir="ltr">&lt;<a href="mailto:ian@hixie.ch">ian@hixie.ch</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
On Thu, 30 Jul 2009, Sebastian Markbåge wrote:<br>
&gt;<br>
&gt; This suggestion seems similar to Digg&#39;s Stream project that uses multipart<br>
&gt; documents: <a href="http://github.com/digg/stream" target="_blank">http://github.com/digg/stream</a><br>
&gt;<br>
&gt; While it would be nice to have a way to parse and handle this in<br>
&gt; JavaScript, it shouldn&#39;t be JavaScript&#39;s responsibility to work with<br>
&gt; large object data and duplicating it as in-memory data strings.<br>
&gt;<br>
&gt; The real issue here is the overhead of each additional HTTP request for<br>
&gt; those thousands of objects. But that&#39;s useful for all parts of the spec<br>
&gt; if you can download it as a single package even without JavaScript.<br>
&gt; Images, CSS, background-images, JavaScript, etc. Currently you can<br>
&gt; include graphics as data URLs in CSS. Using a package you could package<br>
&gt; whole widgets (or apps) as a single request.<br>
&gt;<br>
&gt; I&#39;d suggest that this belongs in a lower level API such as the URIs and<br>
&gt; network stack for the tags. You could specify a file within an archive<br>
&gt; by adding an hash with the filename to the URI:<br>
&gt;<br>
&gt; &lt;img src=&quot;<a href="http://someplace.com/somearchive.tgz#myimage.jpg" target="_blank">http://someplace.com/somearchive.tgz#myimage.jpg</a>&quot; /&gt;<br>
&gt;<br>
&gt; &lt;style type=&quot;text/css&quot;&gt;<br>
&gt; #id { background-image: url(<br>
&gt; <a href="http://someplace.com/somearchive.tgz#mybackgroundimage.jpg" target="_blank">http://someplace.com/somearchive.tgz#mybackgroundimage.jpg</a>); }<br>
&gt; &lt;/style&gt;<br>
&gt;<br>
&gt; &lt;script src=&quot;<a href="http://someplace.com/somearchive.tgz#myscript.js" target="_blank">http://someplace.com/somearchive.tgz#myscript.js</a>&quot;<br>
&gt; type=&quot;text/javascript&quot;&gt;&lt;/script&gt;<br>
&gt;<br>
&gt; var img = new Image();<br>
&gt; img.src = &quot;<a href="http://someplace.com/somearchive.tgz#myimage.png" target="_blank">http://someplace.com/somearchive.tgz#myimage.png</a>&quot;;<br>
&gt;<br>
&gt; Now which packaging format to use would be a discussion on it&#39;s own. An<br>
&gt; easy route would be to use multipart/mixed that is already used for this<br>
&gt; in e-mails and can also be gzipped using Content-Encoding.<br>
<br>
</div></div>This is out of scope for HTML5; I would recommend bringing this up in the<br>
context of the IETF.<br>
<div class="im"><br>
<br>
On Thu, 30 Jul 2009, Kenneth Russell wrote:<br>
&gt;<br>
&gt; In the context of the 3d canvas discussions, it looks like there is a<br>
&gt; need to load binary blobs of vertex data and feed them to the graphics<br>
&gt; card via a JavaScript call. Here is some hypothetical IDL similar to<br>
&gt; what is being considered:<br>
&gt;<br>
&gt;     [IndexGetter, IndexSetter]<br>
&gt;     interface CanvasFloatArray {<br>
&gt;         readonly attribute unsigned long length;<br>
&gt;     };<br>
&gt;<br>
&gt;     interface CanvasRenderingContextGL {<br>
&gt;         ...<br>
&gt;         typedef unsigned long GLenum;<br>
&gt;         void glBufferData(in GLenum target, in CanvasFloatArray data,<br>
&gt; in GLenum usage);<br>
&gt;         ...<br>
&gt;     };<br>
&gt;<br>
&gt; Do you have some suggestions for how the data could be transferred most<br>
&gt; efficiently to the glBufferData call? As far as I know there is no tag<br>
&gt; which could be used to refer to the binary file within the archive. If<br>
&gt; there were then presumably it could provide its contents as a<br>
&gt; CanvasFloatArray or other type.<br>
<br>
</div>We are waiting for the File API specification to be stable, but one that<br>
exists, I would expect it to be used for this kind of thing:</blockquote><div><br>I&#39;m a little confused? Are you saying the File API is part of HTML5 or not?<br><br>Without archive support the File API is not sufficient for the above use case because a typical WebGL app will need to download hundreds of these types of files and it would want to download them compressed.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div><div></div><div class="h5"><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>
</div></div><font color="#888888">--<br>
Ian Hickson               U+1047E                )\._.,--....,&#39;``.    fL<br>
<a href="http://ln.hixie.ch/" target="_blank">http://ln.hixie.ch/</a>       U+263A                /,   _.. \   _\  ;`._ ,.<br>
Things that are impossible just take longer.   `._.-(,_..&#39;--(,_..&#39;`-.;.&#39;</font></blockquote></div><br>