On Jul 18, 2008, at 9:58 AM, Aaron Boodman wrote:
On Thu, Jul 17, 2008 at 4:06 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
On Jul 17, 2008, at 3:53 PM, Aaron Boodman wrote:
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.
So you're saying that in the future XHR.send() could be overloaded to
take blob as an argument too? I guess another way to handle it would
be with inheritance -- File could implement Blob, and then you could
change XHR.send() to take Blob instead of File. Either of these are
fine with me.
XHR.send() already takes many things, so one extra overload is not a
big deal. I can imagine a future design making File be a kind of Blob
instead of having a Blob as in gears, but the idea is that we don't
all have to agree on that now.
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).
On Thu, Jul 17, 2008 at 4:32 PM, Sam Weinig <[EMAIL PROTECTED]> wrote:
Upload progress is possible without manually slicing using the new
upload
progress events proposed in the XMLHttpRequest Level 2 spec.
Sam's point is good. I forgot that we actually have this in Gears
mainly for resumability of large uploads, not for progress (we have
implemented upload progress too).
I can understand this is less necessary for the initial version.
I wonder if it is possible to make resumability more automatic,
somewhat like the way If-Range is used to do resumable downloads. But
manual slicing does seem like an ok solution.
Regards,
Maciej
