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
