Re: [whatwg] An BinaryArchive API for HTML5?

On Tue, Aug 4, 2009 at 6:43 PM, Ian Hickson <ian@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.   `._.-(,_..'--(,_..'`-.;.'