On Thu, 06 Aug 2009 22:05:55 +0200, Gregg Tavares <g...@google.com> wrote:
well, here's an issue that NOT doing it through XMLHttpRequest seems to
bring up.
Say I'm writing word processor or blog posting software. I want to add
the feature where the user can import an RTF file and I'm going to parse
the
file in JavaScript and pull out the text and formatting in stick it in
their current document. If you do it through XMLHttpRequest then there
is one
path the get the data. One way or another the user ends up providing an
URL. That url could be "http://foo.com/mydoc.rtf" or it could be
"filedata: uuid, mydoc.rtf" but I pass that to XMLHttpRequest and I get
back the data in a
consistent way. Otherwise, if you go forward with getting the data
through FileData.get??? methods, there are now two code paths needed, 2
ways to
setup callbacks, 2 ways to get progress events, 2 ways to deal with
errors, etc.
That seems less than ideal to me.
The problem I have with it is that XMLHttpRequest provides an HTTP API.
Not an API got to file data. There's no need for setting the request
method, request headers, request body, etc. when trying to get the data of
file.
You already need different code paths to obtain that URI in the first
place and since they are effectively different processes it might even
make sense to have different UI and code for them as well, including
things like error messages. E.g. for HTTP network errors might occur while
with reading files the file might just have been deleted, moved, etc.
--
Anne van Kesteren
http://annevankesteren.nl/