- From: Kenneth Russell <kbr@google.com>
- Date: Thu, 30 Jul 2009 12:12:16 -0700
- To: Sebastian Markbåge <sebastian@calyptus.eu>, Anne van Kesteren <annevk@opera.com>, Gregg Tavares <gman@google.com>, whatwg@lists.whatwg.org, public-webapps@w3.org
On Thu, Jul 30, 2009 at 6:13 AM, Sebastian Markbåge<sebastian@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@opera.com> > wrote: >> >> On Thu, 30 Jul 2009 08:49:12 +0200, Gregg Tavares <gman@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@w3.org. >> >> >> -- >> Anne van Kesteren >> http://annevankesteren.nl/ > >
Received on Thursday, 30 July 2009 20:56:24 UTC