Re: New FileAPI Draft | was Re: FileAPI feedback

On Thu, 06 Aug 2009 22:05:55 +0200, Gregg Tavares <gman@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/

Received on Saturday, 8 August 2009 13:22:16 UTC