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/
