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

Re: Proposal for an extension XMLHttpRequest to allow sending files

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 18 Jul 2008 14:36:23 -0700
Cc: Sam Weinig <weinig@apple.com>, Web Applications Working Group WG <public-webapps@w3.org>
Message-Id: <4EF5E0E6-C315-4274-BD4B-F4E91175C61E@apple.com>
To: Aaron Boodman <aa@google.com>

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.

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

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