On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote:
On Thu, Jul 17, 2008 at 3:41 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
The Gears proposal has a File object too, as does Mozilla's
extension. We
are proposing making the File object usable directly as an XHR
body, so that
we can all support file upload through XHR interoperably without
first
having to agree on the mechanisms for reading file contents and
representing
binary data (which are different between Gears and Mozilla).
Right, I see the difference now. It is basically:
Gears proposal:
xhr.send(inputElement.files[0].contents);
WebKit proposal:
xhr.send(inputElement.files[0]);
File upload through XHR is useful even without a means to read the
data
client-side, because combined with progress events it can provide
in-page
progress UI with info for multiple files, which is quite a bit
better than
what you get with form submission. Currently some web apps use
Flash for
uploads solely to enable progress UI.
Yup, this is the main reason we proposed this API. Reading the data is
secondary and is not implemented in Gears today or planned for the
near term.
I have two minor concerns with this proposal, both in the cases where
it differs from Gears:
1. Combining the concepts of 'large chunk of binary data' and 'file'
seems unnecessarily coupled to me. It seems likely that in the future
the first concept would be useful in the web api by itself. For
example, in Gears, we have a xhr.responseBlob property. Having a
fileName property here would not always make sense.
I agree! But this proposal doesn't include a concept of 'large chunk
of binary data', only a concept of 'file'. It just lets you send the
file without first turning it into a chunk of binary data. We're not
proposing that the File object should be a generic representation for
any binary data, just that it should be sendable via XHR directly.
2. The slice() method seems important for the initial version,
particularly if you are targeting the large upload use case. We use
this to cut up a large file into smaller pieces so that they can be
uploaded individually. This makes the upload resilient and also allows
the UI to show progress on the upload.
So far the other requests we have had for this functionality have not
needed slicing capability, but nothing in our proposal precludes
adding it (even adding it in a way that's identical to the Gears
proposal would be possible).
Regards,
Maciej
