The latest revision of the FileAPI editor's draft is available here:

These changes constitute a substantial reworking of the original API along the lines of the "Alternative File API" proposal [1]. There are also some additional changes that are worth pointing out explicitly:

1. This editor's draft now resides in a new location in CVS. Essentially, previous repository names had "FileUpload" in them and were confusing, since the API in question had less to do with *uploading a file* than *reading* a file. "FileAPI" is shorter and more intuitive (and better describes what we're doing). Previous drafts are worth keeping as historical artifacts reflecting the decision making of the WG, and so now include a caveat on them pointing them to the draft above.

2. Interface names have changed (notably FileData --> Blob) since the underlying FileData interface had uses on the platform beyond a file read API. "Blob" as an interface name was first introduced by a Google Gears API, which I cite as an informative reference.

3. The event model resembles that of XHR2, with a few differences. Notably, the APIs differ in their use of the 'loadend' ProgressEvent.

4. A suggestion to *not* have a separate scheme ("filedata:") in lieu of urn:uuid:<uuid>[2] has been the basis of a rewrite of that feature in this version of the specification.

I don't anticipate the event model will be controversial, having seen a fair amount of discussion on the listserv. But I do anticipate feedback about 4., as well as the remaining editor's notes.

Looking forward to discussion of this API on this listserv and at the upcoming TPAC :)

-- A*

Reply via email to