- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 5 Aug 2009 01:43:53 +0000 (UTC)
- To: Anne van Kesteren <annevk@opera.com>, Sebastian Markbåge <sebastian@calyptus.eu>, Kenneth Russell <kbr@google.com>
- Cc: Gregg Tavares <gman@google.com>, whatwg@lists.whatwg.org, public-webapps@w3.org
- Message-ID: <Pine.LNX.4.62.0908050140590.6420@hixie.dreamhostps.com>
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: 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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 5 August 2009 01:44:28 UTC