Re: New FileAPI Draft | was Re: FileAPI feedback

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.




>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>