Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)

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).

>> 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.

Reading through the rest of the discussion, I don't think it is - in  
general it would seem useful to have a ByteArray, IMHO.

...
>> 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).

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Tuesday, 13 May 2008 12:09:22 UTC