[whatwg] An BinaryArchive API for HTML5?

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.

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090730/fab263a9/attachment.htm>

Received on Thursday, 30 July 2009 06:13:01 UTC