On May 7, 2008, at 10:08 PM, Aaron Boodman wrote:
Hi everyone,
Opera has a proposal for a specification that would revive (and
supersede)
the file upload API that has been lingering so long as a work item.
The Gears team has also been putting together a proposal for file
access which overlaps in some ways with Opera's, but is also
orthogonal in some ways:
http://code.google.com/p/google-gears/wiki/BlobWebAPIPropsal
I really like the idea of adding consistent APIs for binary data in
the many places in the Web platform that need them. However, I'm not
really clear on why Blobs must be distinct from ByteArrays. The only
explanation is: "The primary difference is that Blobs are immutable*,
and can therefore represent large objects." But I am not sure why
immutability is necessary to have the ability to represent large
objects. If you are thinking immutability is necessary to be able to
have large objects memory mapped from disk, then mmap with a private
copy-on-write mapping should solve that problem just fine.
In fact, immutability seems clearly undesirable for many of these
APIs. Seems like you will want to modify such things and create them
from scratch.
I also notice that you used int64 in many of the APIs. JavaScript
cannot represent 64-bit integers in its number type. All JavaScript
numbers are IEEE floating point doubles. This will lose precision at
the high end of the int64 range, which is likely unacceptable for many
of these APIs. Thus, if 64-bit is really needed, then a primitive type
will not do. You either need two int32s or an object type
encapsulating this.
Regards,
Maciej
I would summarize the key differences this way:
* We introduce a new interface - a blob - that represents an immutable
chunk of (potentially large) binary data
* We propose adding the ability to get and send blobs to many
different APIs, including XHR, the <input type="file"> element,
database, <canvas>, etc.
* We attempt far less interaction with the filesystem (just extending
the input element and allowing exporting a blob to a file).
To answer one of Maciej's questions from the other thread, we intend
this for use on the open web and do not intend for it to require any
particular security authorization.
We would also love feedback, and would like to work with any
interested vendors to iterate this to something others would
implement.
Thanks,
- a
