Last modified: 2011-11-17 19:44:20 UTC
We already use HTML5's FileApi for thumbnails when available (bug 29248), but we could also perform the actual uploads by reading via FileApi and then pushing up. This would be a requirement for resumable downloads (bug 29250) and even without changing protocols should enable better upload progress feedback since we can follow the progress of an XHR submission better than an iframe (bug 24759, bug 30242). Would also allow implementing multi-file uploads (bug 26502) without changing server-side API support to handle multiple files in one POST (bug 16751 etc).
You seem to be proposing an implementation to fix another bug in this bug. Maybe this should not be a bug in itself? It could still be possible to rewrite the upload API method to accept multiple files, especially if these files go directly to stash and do not need their own title or other metadata. That would give us a sort of multiple file support for IE <= 9 and other pre-2010 browsers. However, the XHR/FileReader method is definitely desirable because that gives us much more flexibility and we can start multiple uploads at once, rather than wait for the browser to do them all in sequence. That will work for modern Chrome and Firefox and (hopefully) IE>=10. In principle we can do both, but the implementation is complicated. I've tried to keep a huge wall of separation between "UploadWizardUploadInterface" and "UploadWizardUpload" and the "transports" that each use, for this reason. Considering IE is getting this in version 10 it might be simpler to do everything the FileReader way.
