I'm not sure why he dismisses the FileAPI right away... one of the goals of the Reader according to http://www.w3.org/TR/FileAPI/ is:
User agents should provide a streamlined programmatic ability to send data from a file to a remote server that works more efficiently than form-based uploads today
Example: A Video/Photo Upload App. User is able to select large files for upload, which can then be "chunk-transfered" to the server.
This means that although this XMLHttpRequest2 method is nice, in practice it will still suffer from all the issues that http uploads suffer from at the moment. Chunked uploading, which the W3C spec explicitly supports, would be a much better solution for large files, no?
The FileReader API allows you to do some cool things, but I wanted to avoid chunked uploading for a few reasons. First, it's way more complex to handle given the way our app currently deals with files, and second, there isn't nearly as much existing browser support for both the Blob interface and FileReader in general. This post deals a bit with the current state of things:
The FileAPI has even less support than XMLHttpRequest 2. Specifically, you are linking to a spec that was updated on tuesday of this week: "W3C Working Draft 26 October 2010". It will be excellent once we can do chunked uploads but this is still a vastly better experience then <file> fields!
User agents should provide a streamlined programmatic ability to send data from a file to a remote server that works more efficiently than form-based uploads today
Example: A Video/Photo Upload App. User is able to select large files for upload, which can then be "chunk-transfered" to the server.
This means that although this XMLHttpRequest2 method is nice, in practice it will still suffer from all the issues that http uploads suffer from at the moment. Chunked uploading, which the W3C spec explicitly supports, would be a much better solution for large files, no?