- From: Gregg Tavares <gman@google.com>
- Date: Tue, 4 Aug 2009 21:13:29 -0700
On Tue, Aug 4, 2009 at 6:43 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Thu, 30 Jul 2009, Sebastian Markb?ge wrote: > > > > This suggestion seems similar to Digg's Stream project that uses > multipart > > documents: http://github.com/digg/stream > > > > While it would be nice to have a way to parse and handle this in > > JavaScript, it shouldn't be JavaScript's responsibility to work with > > large object data and duplicating it as in-memory data strings. > > > > The real issue here is the overhead of each additional HTTP request for > > those thousands of objects. But that'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. > > > > I'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: > > > > <img src="http://someplace.com/somearchive.tgz#myimage.jpg" /> > > > > <style type="text/css"> > > #id { background-image: url( > > http://someplace.com/somearchive.tgz#mybackgroundimage.jpg); } > > </style> > > > > <script src="http://someplace.com/somearchive.tgz#myscript.js" > > type="text/javascript"></script> > > > > var img = new Image(); > > img.src = "http://someplace.com/somearchive.tgz#myimage.png"; > > > > Now which packaging format to use would be a discussion on it'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. > > This is out of scope for HTML5; I would recommend bringing this up in the > context of the IETF. > > > On Thu, 30 Jul 2009, Kenneth Russell wrote: > > > > In the context of the 3d canvas discussions, it looks like there is a > > need to load binary blobs of vertex data and feed them to the graphics > > card via a JavaScript call. Here is some hypothetical IDL similar to > > what is being considered: > > > > [IndexGetter, IndexSetter] > > interface CanvasFloatArray { > > readonly attribute unsigned long length; > > }; > > > > interface CanvasRenderingContextGL { > > ... > > typedef unsigned long GLenum; > > void glBufferData(in GLenum target, in CanvasFloatArray data, > > in GLenum usage); > > ... > > }; > > > > Do you have some suggestions for how the data could be transferred most > > efficiently to the glBufferData call? As far as I know there is no tag > > which could be used to refer to the binary file within the archive. If > > there were then presumably it could provide its contents as a > > CanvasFloatArray or other type. > > We are waiting for the File API specification to be stable, but one that > exists, I would expect it to be used for this kind of thing: I'm a little confused? Are you saying the File API is part of HTML5 or not? 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. > > > http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090804/283ba961/attachment.htm>
Received on Tuesday, 4 August 2009 21:13:29 UTC