On Tue, 20 Oct 2009 18:47:59 +0200, Anne van Kesteren <ann...@opera.com>
wrote:
On Tue, 20 Oct 2009 18:27:36 +0200, Darin Fisher <da...@chromium.org>
wrote:
On Tue, Oct 20, 2009 at 4:31 AM, Anne van Kesteren <ann...@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
