Re: File API, Editor's Draft II

Robin,
>
>   - The indentation of your WebIDL snippets is a bit broken, which 
> makes them hard to read.
>
I've got this nit numerous times; I'm going to fix it.
>   - 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>.
I discussed this on #whatwg.  Definitely, the sequence<T> syntax is much 
more elegant, but it isn't ready yet. 

I think FileList's existence primarily as an [IndexGetter] for File 
doesn't hurt too much.
>
>   - 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?
Agreed.
>
>   - 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.
>
I actually want to rework this based on other feedback obtained in IRC 
(about having FileData as separate from File).  I'll circulate that for 
review.
>   - 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.
Agreed.
>   - 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).
>
Hmm.. the proposal which I received via IRC was to split what is now 
"File" into FileData (everything *but* name) and File (name), with File 
inheriting from FileData.  Perhaps mediaType could go with File.
>   - 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).
Yes.  I've made permission solicitation a MAY pending further discussion 
with UAs.
>
>   - 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.
I should make this clearer, but currently if the user cancels, the 
FileErrorCallback will be called with FileError (with errorCode 
SECURITY_ERR).  Subsequent suggestions from Anne to NOT match what 
DOMException does might mean cleaning up my error codes and adding some 
new ones.
>
>   - 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.
Having cancel() on *what objects* exactly?  Also, WindowTimer may not be 
the best example.
>
>   - 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?
>
In my opinion, charset conversion shouldn't throw any errors, but should 
try to honor the call as best as possible.  I'll make this clearer.

All of these are good nits -- thank you!


-- A*

Received on Thursday, 18 June 2009 21:02:45 UTC