W3C home > Mailing lists > Public > public-webapi@w3.org > May 2008

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

From: Aaron Boodman <aa@google.com>
Date: Sun, 11 May 2008 16:08:48 -0700
Message-ID: <278fd46c0805111608n8580054x6ab99aee8454d41b@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Chris Prince <cprince@google.com>, "Web API WG (public)" <public-webapi@w3.org>, Ian Hickson <ian@hixie.ch>

On Sun, May 11, 2008 at 3:02 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> Both of these can be addressed by the APIs (including the worker transfer
> mechanism) making a copy, which can use a copy-on-write mechanism to avoid
> actually making a copy in the common case.

Ok, so just so I'm clear, does the following example snippet
accurately reflect how you propose that things work?

var req = new XMLHttpRequest();
req.open("GET", "example", true);
req.onreadystatechange = handleResult;
req.send(null);

function handleResult() {
  if (req.readyState != 4) return;

  var b1 = req.responseByteArray;
  var b2 = b1;
  assert(b1 === b2); // they refer to the same object

  // print the contents of the array
  for (var i = 0; i < b1.length; i++) {
    print(b1[i]);
  }

  b1[0] = 42;
  assert(b2[0] == 42);

  var worker = window.createWorker("worker.js");
  worker.sendMessage(b1); // branches b1
  b1[0] = 43; // modification does not affect what got sent to worker
}

// worker.js
worker.onmessage = function(b) {
  assert(b[0] == 42);
};

> I'm still not convinced that immutability is good, or that the ECMAScript
> ByteArray proposal can't handle the required use cases.

Here's one additional question on how this would work with ByteArray.
The read API for ByteArray is currently synchronous. Doesn't this mean
that with large files accessing bytearray[n] could block?

- a
Received on Sunday, 11 May 2008 23:09:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 11 May 2008 23:09:27 GMT