I have updated the draft of the File API, and welcome more review. Note
that it is no longer called "FileUpload" since this term has become
misleading.
In particular, here are some of the issues addressed (and some not):
> Any reason you're using an XHTML file to edit this? Also, the
indentation is awkward.
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
> For what concerns the "file as URI" feature:
>What about reusing the "cid" scheme?
After having looked at the RFCs for cid and mid schemes, I don't think
the cid scheme is appropriate for our use case, since it is tightly tied
to the notion of message body, which isn't necessarily true in all cases
of file data.
I have a proposal in this draft for the "file as URL" proposal
(originally broached in IRC, but which has seen some discussion on the
listserv). I'd welcome feedback on it, especially the processing model
for these URLs. A simple ABNF using UUIDs as unique identifiers has
been proposed here.
> File API should probably have some way to get only parts of the file.
This has been added as a new method. Feedback welcome!
>[The existing design] limits the number of callbacks to one. That one
callback
>can only be added in the invocation to read.
>Instead, allow multiple callbacks to be added with the DOM Events API
While this was an intriguing suggestion (and seemed like it was a more
powerful programming model), I wasn't convinced that it was needed for
the File API. It did lead to a more complicated model that didn't seem
to fully justify the power. However, I did study subsequent use cases,
and eliminated error callbacks, allowing callbacks themselves to handle
error conditions. Also, I introduced a cancelReads( ) which can be used
with timeouts. I'm not convinced that an event model is necessary for
asynchronous data accessors on file data; DOM events aren't useful in
all cases. It's also worth nothing that the File API in general may be
subject to further iteration in the Device API WG, which may introduce
notions of "write" APIs.
>Note of course that whatever API supports ranges needs to ensure that
>the data isn't forcibly coerced into valid Unicode, as the underlying
>data for an image can include all sorts of patterns which aren't valid
>UTF8/16/....
It was clear that getAsText was insufficient, so more asynchronous data
accessor methods have been added.
> I think FileDialog is a bad idea. We already have UI for selecting
multiple files: <input type=file
>multiple>.
This has now been eliminated from this draft. I'm keen to move towards
fpwd, and it seemed that FileDialog was needlessly controversial. I
think it still is useful, and think it could be added later.
-- A*
