Re: File API, Editor's Draft II

Hey Arun,

On Jun 11, 2009, at 12:34 , Arun Ranganathan wrote:
> I'd like review on the most recent draft of the File API

Just a few things on first pass, in a good spec:

   - Great idea listing the defined interfaces with links in the  
abstract, makes quick access easy; this should be standard for all API  
specs.

   - The indentation of your WebIDL snippets is a bit broken, which  
makes them hard to read.

   - Do we want to keep FileList? I think we're all tired of those. I  
know that the sequence<T> section of WebIDL hasn't been written, but  
this could be a good way of encouraging Cameron :) I'd personally be  
all for killing that interface and just using sequence<File>.

   - FileAsText is poorly named IMHO, I had to reparse the description  
of getAsDataURI several times before I realised that it used  
FileAsText (which on quick read was immediately classified as "for  
getAsText"). How about just FileContent?

   - It might be useful if the FileAsText (or FileContent) callback  
got a second argument telling it what kind of data it's getting (in  
this case "text" or "dataUri"). No strong feelings on this, just a  
thought I'm putting out there.

   - There's some lexicographic confusion around URI/URL (for a  
change). Data URLs are called, well Data URLs (as per RFC 2397) and  
it's also the terminology you use in the prose. Yet the method is  
called getAsDataURI. Consistency wouldn't hurt, I don't really care  
which way.

   - Suggestion: how about having a mediaType attribute on File? The  
system usually knows such things (I believe) and it could be useful  
for scripts to decide what to do based on what users have picked, or  
to correctly label the file when interacting with a service (e.g. DAV).

   - Flash doesn't ask permission to show the file picker, but it  
requires genuine interaction (as of F10 you can't trigger it without  
interacting with Flash content).

   - For FileListDataCallback what happens if the user cancels? Do I  
get an error? A defined but empty FileList? I have a slight preference  
for the latter, but either way the author should be notified.

   - General note on asynchronous calls: instead of void, should they  
return an opaque token which can be used to cancel the request (or  
provide one way or another of doing that, possibly just having  
cancel() on the object)? That's available on setTimeout/setInterval,  
and on XHR — it's generally useful.

   - How do you propose to handle encoding errors? Say a file is UTF8  
and I request it as ASCII? Drop what can't be converted? Use a  
replacement character? Throw an error?

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/

Received on Wednesday, 17 June 2009 07:14:24 UTC