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

Responses to several of the comments so far:

On Fri, May 9, 2008 at 9:15 PM, Ian Hickson <ian@hixie.ch> wrote:
> I'm not sure I like the way that the bytes are made accessible, but
> that's a minor detail really.

I tend to agree.  The 'Creating Blobs' section and the readAs*()
methods were added last-minute.  We don't know of apps that need that
functionality at present.  And binary manipulation seems unlikely to
be satisfying until ES4 anyway.  Personally, I think it's reasonable
to remove these sections from the Blob spec for now.


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

Making Blobs immutable simplifies a number of problems:

(1) Asynchronous APIs.

Large Blobs can be passed to XmlHttpRequest for an asynchronous POST,
or to Database for an asynchronous INSERT.  If Blobs are mutable, the
caller can modify the contents at any time.  The XmlHttpRequest or
Database operation will be undefined.

Careful callers could wait for the operation to finish (at least in
these two examples; I'm not sure about all possible scenarios).  But
this is starting to put quite a burden on developers.

(2) HTML5 Workers.

There are cases where apps will get a Blob on the UI thread, and then
want to operate on it in a Worker.  Note that the Blob may be
file-backed or memory-backed.

Worker threads are isolated execution environments.  If Blobs are
mutable, it seems like tricky (or impossible) gymnastics would be
required to ensure one thread's file writes aren't seen by another
thread's reads, unless you create a copy.  And that is doubly true for
memory-backed blobs.

(I'm not even considering older mobile operating systems, which may
not have all the file and memory capabilities of modern OSes.)


~~~

There is another, slightly different issue around mutability, which
hasn't really been called out yet.  It affects whether Blobs should be
directly readable.

One of the biggest motivations for Blobs was to do interesting things
with local files.  But these files may be modified by programs outside
the browser.

It would be pretty crazy if developers had to guard against the
'length' field changing between any two lines of JavaScript.

Locking files appears to be impossible on some platforms. (Even when
it is possible, the experience can be unsatisfying; anybody who has
seen a "file is locked" error -- with no additional info -- knows this
feeling.)  So our plan has been to check the file modification time
whenever a Blob's contents are read.

If Blobs are directly accessible, an exception could occur any time
the web app reads the contents.  If Blobs are not directly accessible
(as I would propose), then to developers, it only means methods that
accept Blob arguments may throw.

--Chris

Received on Sunday, 11 May 2008 10:39:07 UTC