- From: Oliver Hunt <oliver@apple.com>
- Date: Mon, 24 Sep 2007 22:59:55 -0700
On 24/09/2007, at 10:45 PM, Robert O'Callahan wrote: <snip> > > For small files, synchronous reading is OK. Perhaps there should be > a separate whiz-bang asynchronous API ... it could support partial > reads too. I would be concerned about this -- for many people async APIs seem scary compared to synchronous ones, and people will end up doing silly things (excessive reads, etc) using a synchronous API, eg. synchronous api for large reads, or many sequential small synchronous reads -- either of which will block the main thread in excitingly bad ways. I would make the argument that anyone making a real webapp (online or offline) is likely to have at least *some* experience with async-xhr, so should have to much difficulty with an async api for reading/writing. > > > Also, I'm not sure how a web app can be expected to know the encoding > of a text file on disk. > > The same way that any other app does --- guess based on the > extension and expected usage? --- now that we've all standardized > on meta-data-less file systems :-(. I suppose an app could examine > the first chunk of the file and then re-read the file with a better > guess. The MacOS fs appears to store encoding, but then maybe editors are more careful about including the BOM, etc in files that they save. Surely it would be possible for the browser to transparently store the encoding in the event that none was defined by the developer? > Rob --Oliver
Received on Monday, 24 September 2007 22:59:55 UTC