- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 6 Aug 2009 21:09:07 -0700
- To: Gregg Tavares <gman@google.com>
- Cc: Anne van Kesteren <annevk@opera.com>, arun@mozilla.com, Dmitry Titov <dimich@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
On Thu, Aug 6, 2009 at 1:05 PM, Gregg Tavares<gman@google.com> wrote: > > > On Thu, Aug 6, 2009 at 2:35 AM, Anne van Kesteren <annevk@opera.com> wrote: >> >> On Thu, 06 Aug 2009 10:53:31 +0200, Gregg Tavares <gman@google.com> wrote: >>> >>> On Thu, Aug 6, 2009 at 12:48 AM, Anne van Kesteren <annevk@opera.com> >>> wrote: >>>> >>>> XHR does not do local data. It also does not do raw file data very well. >>> >>> I don't quite understand this comment. Isn't the point of these >>> discussions how to extend browsers and HTML? XHR was just extended to >>> support cross-site requests and new properties were added. Couldn't it be >>> extended again to >>> support local files (through the "filedata:" url system) and as well to >>> support raw data? >> >> Sorry, it indeed could be extended in that way. I just think it is a bad >> idea. XMLHttpRequest provides an almost complete HTTP API and such a thing >> is completely different and way more complex than what is needed to read >> files from disk. In addition XMLHttpRequest is quite complex and overloading >> the whole object and all its members with this functionality is not worth >> saving a few members on the File/FileData objects. > > 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. Note that with the current API it is actually possible to use XMLHttpRequest. If you use the getAsURL function, you get a URL which you can then pass to the XMLHttpRequest.open function. I don't believe we've fully looked at the implications of this, but at first glance it seems possible. / Jonas
Received on Friday, 7 August 2009 04:10:07 UTC