Re: Proposal for an extension XMLHttpRequest to allow sending files

On Jul 18, 2008, at 9:58 AM, Aaron Boodman wrote:

> On Thu, Jul 17, 2008 at 4:06 PM, Maciej Stachowiak <mjs@apple.com>  
> 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 <weinig@apple.com> 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

Received on Friday, 18 July 2008 21:37:06 UTC