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

On Sat, May 10, 2008 at 1:18 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> I really like the idea of adding consistent APIs for binary data in the many
> places in the Web platform that need them. However, I'm not really clear on
> why Blobs must be distinct from ByteArrays. 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. If you are thinking immutability is
> necessary to be able to have large objects memory mapped from disk, then
> mmap with a private copy-on-write mapping should solve that problem just
> fine.

I'm going to defer to Chris Prince on this question, as he is the real
man behind this proposal on our team and has thought the most about
it. Not knowing much about mmap, it sounds like a fair enough idea to
me. It seems like you'd eventually still want to push things back to
disk after enough mutation, right? Would writes be synchronous? Would
reads?

> In fact, immutability seems clearly undesirable for many of these APIs.
> Seems like you will want to modify such things and create them from scratch.

We agree that you'd want to modify and create blobs, and have a TODO
for that in our proposal. However, we were thinking of handling this
similarly to how strings are handled in JavaScript. When you modify a
blob, you get a new blob instance.  But our ideas on this are pretty
poorly formed as we don't have as pressing a need as we do for the
things we've proposed so far.

> I also notice that you used int64 in many of the APIs. JavaScript cannot
> represent 64-bit integers in its number type. All JavaScript numbers are
> IEEE floating point doubles. This will lose precision at the high end of the
> int64 range, which is likely unacceptable for many of these APIs. Thus, if
> 64-bit is really needed, then a primitive type will not do. You either need
> two int32s or an object type encapsulating this.

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?

On Sat, May 10, 2008 at 7:51 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Sun, 11 May 2008, Charles McCathieNevile wrote:
>>
>> > Do we have the resources to have someone champion this spec?
>>
>> Are you asking the WG, or Google?
>
> The Web community as a whole. I don't care which working group (if any)
> "owns" it, and I don't have any reason to prefer that Google work on this
> rather than anyone else -- my interest is in forwarding the platform as a
> whole. :-)

I think I might like to do this. What does it involve? Should we take
this part offline, Ian?

- a

Received on Sunday, 11 May 2008 03:11:41 UTC