W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: New FileAPI Draft | was Re: FileAPI feedback

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 6 Aug 2009 21:09:07 -0700
Message-ID: <63df84f0908062109x7ea45f71s126d13cb7c574ed2@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT