- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 13 May 2008 14:08:37 +0200
- To: "Aaron Boodman" <aa@google.com>, "Web API WG (public)" <public-webapi@w3.org>
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