W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

Re: File API, Editor's Draft II

From: Arun Ranganathan <arun@mozilla.com>
Date: Thu, 18 Jun 2009 14:02:06 -0700
Message-ID: <4A3AAB4E.3070004@mozilla.com>
To: Robin Berjon <robin@berjon.com>
CC: public-webapps <public-webapps@w3.org>
>   - 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?
>   - 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 
>   - 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).
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC