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

On May 7, 2008, at 10:08 PM, Aaron Boodman wrote:

>
> Hi everyone,
>
>> Opera has a proposal for a specification that would revive (and  
>> supersede)
>> the file upload API that has been lingering so long as a work item.
>
> The Gears team has also been putting together a proposal for file
> access which overlaps in some ways with Opera's, but is also
> orthogonal in some ways:
>
> http://code.google.com/p/google-gears/wiki/BlobWebAPIPropsal

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.

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.

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.

Regards,
Maciej


>
>
> I would summarize the key differences this way:
>
> * We introduce a new interface - a blob - that represents an immutable
> chunk of (potentially large) binary data
> * We propose adding the ability to get and send blobs to many
> different APIs, including XHR, the <input type="file"> element,
> database, <canvas>, etc.
> * We attempt far less interaction with the filesystem (just extending
> the input element and allowing exporting a blob to a file).
>
> To answer one of Maciej's questions from the other thread, we intend
> this for use on the open web and do not intend for it to require any
> particular security authorization.
>
> We would also love feedback, and would like to work with any
> interested vendors to iterate this to something others would
> implement.
>
> Thanks,
>
> - a
>

Received on Saturday, 10 May 2008 08:19:17 UTC