W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [whatwg] An BinaryArchive API for HTML5?

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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT