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. > / Jonas >
Received on Tuesday, 27 April 2010 00:23:09 UTC