W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2009

[whatwg] An BinaryArchive API for HTML5?

From: Kenneth Russell <kbr@google.com>
Date: Thu, 30 Jul 2009 12:12:16 -0700
Message-ID: <921bb10907301212v59d8a67cqf284295da14e6dd0@mail.gmail.com>
On Thu, Jul 30, 2009 at 6:13 AM, Sebastian
Markb?ge<sebastian at calyptus.eu> 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.

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.

-Ken

> On Thu, Jul 30, 2009 at 11:41 AM, Anne van Kesteren <annevk at opera.com>
> wrote:
>>
>> On Thu, 30 Jul 2009 08:49:12 +0200, Gregg Tavares <gman at google.com> wrote:
>> > What are people's feelings on adding a Binary Archive API to HTML5?
>>
>> I think it makes more sense to build functionality like this on top of the
>> File API rather than add more things into HTML5.
>>
>>
>> > It seems like it would be useful if there was browser API that let you
>> > download something like gzipped tar files.
>>
>> We already have that: XMLHttpRequest.
>>
>>
>> > The API would look something like
>> >
>> > var request = createArchiveRequest();
>> > request.open("GET", "http://someplace.com/somearchive.tgz");
>> > request.onfileavailable = doSomethingWithEachFileAsItArrives;
>> > request.send();
>>
>> I don't think we should introduce a new HTTP API.
>>
>>
>> > function doSomethingWithEachFileAsItArrives(binaryBlob) {
>> > ? // Load every image in archive
>> > ? if (binaryBlob.url.substr(-3) == ".jpg") {
>> > ? ? ?var image = new Image();
>> > ? ? ?image.src = binaryBlob.toDataURL(); ?// or something;
>> > ? ? ?...
>> > ? }
>> > ? // Look for a specific text file
>> > ? else if (binaryBlog.url === "myspecial.txt") {
>> > ? ? // getText only works if binaryBlob is valid utf-8 text.
>> > ? ? var text = binaryBlob.getText();
>> > ? ? document.getElementById("content").innerHTML = text;
>> > ? }
>> > }
>>
>> Having dedicated support for a subset of archiving formats in within the
>> API for File objects makes sense to me. Latest draft of the File API I know
>> of is
>>
>> ?http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
>>
>> and the mailing list would be public-webapps at w3.org.
>>
>>
>> --
>> Anne van Kesteren
>> http://annevankesteren.nl/
>
>
Received on Thursday, 30 July 2009 12:12:16 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:14 UTC