W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2010

Re: XMLHttpRequest.responseBlob

From: Jonas Sicking <jonas@sicking.cc>
Date: Mon, 26 Apr 2010 17:51:05 -0700
Message-ID: <l2k63df84f1004261751nf1c1867fue6d809e29f46aaab@mail.gmail.com>
To: Michael Nordman <michaeln@google.com>
Cc: Thomas Broyer <t.broyer@gmail.com>, Darin Fisher <darin@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
On Mon, Apr 26, 2010 at 5:22 PM, Michael Nordman <michaeln@google.com> wrote:
> On Mon, Apr 26, 2010 at 4:24 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Mon, Apr 26, 2010 at 4:19 PM, Thomas Broyer <t.broyer@gmail.com> wrote:
>> > On Tue, Apr 27, 2010 at 1:11 AM, Jonas Sicking <jonas@sicking.cc> 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.

It does mean though that a UA which doesn't want to use synchronous IO
will have to keep all the data in memory, and thus not fulfill what I
understood to be Darin's requirement.

As far as I know that means at least firefox and safari. Don't know
how the other browsers feel about it.

/ Jonas
Received on Tuesday, 27 April 2010 00:51:58 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:24 UTC