Responses to several of the comments so far: On Fri, May 9, 2008 at 9:15 PM, Ian Hickson <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
