W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2008

Re: Proposal for an extension XMLHttpRequest to allow sending files

From: Aaron Boodman <aa@google.com>
Date: Fri, 18 Jul 2008 09:58:00 -0700
Message-ID: <278fd46c0807180958ra362230n95280431aa6bfa27@mail.gmail.com>
To: "Maciej Stachowiak" <mjs@apple.com>
Cc: "Sam Weinig" <weinig@apple.com>, "Web Applications Working Group WG" <public-webapps@w3.org>

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.

>> 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.

- a
Received on Friday, 18 July 2008 16:58:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:11 UTC