W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2009

Re: Proposal for sending multiple files via XMLHttpRequest.send()

From: Charles McCathieNevile <chaals@opera.com>
Date: Tue, 20 Oct 2009 20:00:25 +0200
To: "Anne van Kesteren" <annevk@opera.com>, "Darin Fisher" <darin@chromium.org>
Cc: public-webapps@w3.org
Message-ID: <op.u131mzo3wxe0ny@widsith.local>
On Tue, 20 Oct 2009 18:47:59 +0200, Anne van Kesteren <annevk@opera.com>  
wrote:

> On Tue, 20 Oct 2009 18:27:36 +0200, Darin Fisher <darin@chromium.org>  
> wrote:
>> On Tue, Oct 20, 2009 at 4:31 AM, Anne van Kesteren <annevk@opera.com>  
>> wrote:
>>> If eventually we get native support for octet-arrays and all we can at  
>>> that point add the ability to XMLHttpRequest so you can send anything  
>>> you want.
>>
>> Hmm, OK
>
> If you envision things differently, by all means say so :-)

So, I envision things a bit differently from Anne (as he and I have  
discussed in relation to Progress events).

>>>  If we do go the more specific route, then it could look like this:
>>>>
>>>> var data = new FormData;
>>>> data.appendText("name1", "value");
>>>> data.appendFile("name2", fileData);
>>>> xhr.send(data);
>>>>
>>>> The UA could populate the filename attribute of the  
>>>> Content-Disposition
>>>> header based on the given fileRef.  Same goes for the Content-Type  
>>>> header.
...

My rough idea is that you have a set of things being sent, as per  
appcache. You collect them somehow (I have no particular opinion on  
formdata or something else), and send them, as transaction that sends a  
bunch of objects.

The thinking behind adding loadedItems and totalItems to progress events  
(as Anne says, maybe having the existing simple interface and a longer one  
that inherits and adds the extra attributes is a good idea) was that you  
could then provide progress information both on a "what object has gone"  
basis, and "how much of this object has gone".

The way I came up with effectively supposes an array of items, and the  
loadedItems (where present) acts as an index to the array. A natural  
consequence of this is that if somehow you are sending the objects out of  
order, you still give progress information on a per-object basis. (This  
wasn't actually a goal, it just happens that way).

The point of ISSUE-107 was that I envisaged sending a load event for each  
object (as currently written appcache sends a progress event) when it is  
loaded, with a single loadstart and a single loadend for the entire  
transaction. Optionally, you can send a progress event where part of an  
object has been transmitted. Obviously this is a change to appcache -  
albeit I believe a relatively small one, substituting the current events  
sent for slightly different ones. In principle you would add the size of  
the object, as the loaded attribute of the load event sent, but in  
practice that's probably not necessary (note to self - the spec doesn't  
say what you put. Maybe it should allow a dummy value, but maybe not...).

A consequence of this model is that when you get the events you can find  
out which things got shifted, and decide whether to go back and try again  
if something dropped. I have repeatedly seen, because it takes nothing  
more than looking, pages come through apparently missing an icon or  
something which doesn't matter, in which case it would be useful if the  
app started working and just tried to refetch the missing icon in the  
background. If some critical script is missing, you need to go back and  
get it. As Anne says, this is potentially more complicated - but nothing  
obliges you to use it. If you get any error or abort instead of a load you  
can simply insist on reloading until you have everything. But it seems to  
me this provides authors with the ability to write applications that are  
more robust on flaky networks (or dealing with flaky servers), if they  
choose to do so.

As far as I can tell it would be feasible to implement this without  
changing Anne's proposal. At the same time, this would allow for other  
APIs (appcache5, or fetchMail, or whatever) to use progress events more or  
less as they are in the new editor's draft [1]. However, this week I will  
talk to the implementors at Opera and see what they think - and I hope  
also to get feedback from Hixie on this.

[1]  
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.32

thoughts?

cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals       Try Opera: http://www.opera.com
Received on Tuesday, 20 October 2009 18:01:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:34 GMT