Re: [whatwg] An BinaryArchive API for HTML5?
On Tue, 4 Aug 2009, Gregg Tavares wrote: 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? The File API is a separate spec: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml 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. Ah, indeed. Yeah, in that case you probably want an IETF-level spec like multipart/related, with a URL scheme to refer to subfiles within it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] An BinaryArchive API for HTML5?
On Tue, Aug 4, 2009 at 6:43 PM, Ian Hickson i...@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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] An BinaryArchive API for HTML5?
On Thu, 30 Jul 2009 08:49:12 +0200, Gregg Tavares g...@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-weba...@w3.org.
--
Anne van Kesteren
http://annevankesteren.nl/
Re: [whatwg] An BinaryArchive API for HTML5?
On Thu, Jul 30, 2009 at 6:13 AM, Sebastian
Markbågesebast...@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 ann...@opera.com
wrote:
On Thu, 30 Jul 2009 08:49:12 +0200, Gregg Tavares g...@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-weba...@w3.org.
--
Anne van Kesteren
http://annevankesteren.nl/
