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

What I think we really want is a script-only means of sending multipart
form-data encoding POSTs that contain a mix of file- parts and binary-parts
(in addition to the ability to send the raw contents of a file).
* script-only, so these POSTs can be performed in workers
* multipart form-data, its the defacto standard

The Gears stab at this was BlobBuilder, which let developers compose
something with a mix of utf8 encoded strings and binary ile data, and
Gears.HttpRequest.send(blob). Developers were left to their own devices to
produce a valid mulitpart form-data encoded blob by manually stitching
together the parts with appropiate boundaries and such, and then setting the
content-type on the request properly prior to sending. Somewhat tedious for
developers but it worked.

The Gears team had considered expressing things as an array with a mix of
strings and Blobs, and then sending the array as well, but shied away from
that because we .send([]) already has a meaning (as has been pointed out in
this thread).

Another way to expose this capability in a script-only way could be the
introduction of a new object for this purpose.

class FormData {
  addString(name, value);
  addFile(name, file);  // maybe optional params for additional
content-disposition headers?
}
xhr.send(formData);






2009/9/12 Alfonso Martínez de Lizarrondo <amla70@gmail.com>

> > Since XMLHttpRequest spec has already added the overload for
> send(document),
> > why not just adding more overload for file and array of items? IMHO,
> having
> > similar send*** methods, like sendFile, together with overloads of send()
> > might make the API more complicated.
>
> If the browser doesn't provide any system to detect that it supports
> this feature, then the only way to enable it is to do UA sniffing, and
> I thought that everyone agreed that this is bad because when the code
> is deployed it must be updated for each new browser that implements
> this API.
>
> I wrote about my point of view about this kind of features in
> http://alfonsoml.blogspot.com/2009/08/upload-progress-for-firefox-35.html
> As I said there, if other browser implements that API the code will
> work automatically for them. It's not a problem to add new code to
> support a new API, but make it work based on UA it isn't nice.
>
>