On May 13, 2008, at 5:08 AM, Charles McCathieNevile wrote:
On Sun, 11 May 2008 05:10:57 +0200, Aaron Boodman <[EMAIL PROTECTED]>
wrote:
On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
... I'm not really clear on why Blobs must be distinct from
ByteArrays.
As I read it, the Blob proposal also explicitly ties in a bit of
file interaction (which is why it is related to the fileIO proposal).
That seems to be where things are evolving, but in the original
proposal Blobs were also to be used for such things as the binary
image data in a <canvas>, or binary data retrieved by XMLHttpRequest,
or binary data dynamically generated by script. (I proposed renaming
Blob to File because I think the non-file uses are better served via
ByteArray).
...
I also notice that you used int64 in many of the APIs. JavaScript
cannot
represent 64-bit integers in its number type. ...
I think our assumption is that 2^53 is large enough to represent the
length of all the blobs going in and out of web apps for the
forseeable future. We would just throw when we receive a number that
is larger than that saying that it is out of range. Is there a better
way to notate this in specs?
Well, you at least have to be pretty explicit about it I think.
Better would be to find a type that Javascript can do, though.
(I suspect that if we are still relying on a thing called 'blob'
because we still don't have real file system access with some sense
of security by the time we want to hand around a Terabyte in a web
application, that we will have seriously failed somewhere. Although
it isn't impossible that we end up there).
I see no reason the Blob proposal couldn't handle uploading a Terabyte
of data. 2^53 > 10^4. Indeed, for data that large you really do want a
filesystem reference that you can hand directly to a network API so it
can be sent without having to load the whole thing into memory via
script.
Regards,
Maciej
