W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 13 May 2008 09:20:00 -0700
Cc: Aaron Boodman <aa@google.com>, "Web API WG (public)" <public-webapi@w3.org>
Message-Id: <8BEB5C4B-5349-4D83-A85C-2433D3287FA0@apple.com>
To: Charles McCathieNevile <chaals@opera.com>

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  

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

Received on Tuesday, 13 May 2008 17:56:08 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:26 UTC