Re: XMLHttpRequest.responseBlob

On Mon, Apr 26, 2010 at 4:24 PM, Jonas Sicking <> wrote:

> On Mon, Apr 26, 2010 at 4:19 PM, Thomas Broyer <> wrote:
> > On Tue, Apr 27, 2010 at 1:11 AM, Jonas Sicking <> wrote:
> >>
> >> I'm not sure I understand how you envision the implementation working.
> >> You can't before hand know that the implementation won't ever access
> >> those properties (at least not without solving the halting problem).
> >> So you'll have to keep all the data in memory, just in case
> >> .reponseText is accessed.
> >
> > Couldn't you stream to disk, and in case responseText or responseXML
> > is called then read back from disk? You'd then have to "keep all the
> > data in memory" only when .responseText is used.
> That requires synchronous IO, something we're trying hard to avoid.
> Apple has said in the past that they are not willing to implement APIs
> that require synchronous IO. And in Firefox we're working on removing
> all places where it's used. Both in the implementation of various
> features exposed to web pages, but also in the product itself.

(geez halting problem)

Spill over to disk as a response gets "too big", a function of memory
available on the device. If a response gets "too big" its possibly being
swapped in VM anyway. You may know if its "too big" from the get go based on
content-length headers.

So if responseText is accessed on "too big" of a resource, yes that may
involve explicit file system IO (big deal). There's a trade off here...
cleaner API vs quirky API to make life easier for the user-agent. I was
leaning towards cleaner API.


/ Jonas

Received on Tuesday, 27 April 2010 00:23:09 UTC