On May 13, 2008, at 5:08 AM, Charles McCathieNevile wrote:
>
> On Sun, 11 May 2008 05:10:57 +0200, Aaron Boodman <aa@google.com>
> wrote:
>
>> On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <mjs@apple.com>
>> 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