New FileAPI Draft | was Re: FileAPI feedback

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*

Received on Wednesday, 5 August 2009 01:56:04 UTC