Re: [XHR2] Blobs, names and FormData

On Wed, Aug 31, 2011 at 12:07 AM, Charles Pritchard <chuck@jumis.com> wrote:
> On 8/30/2011 7:11 PM, Jonas Sicking wrote:
>>
>> On Tue, Aug 30, 2011 at 5:59 PM, Charles Pritchard<chuck@jumis.com>
>>  wrote:
>>>
>>> On 8/30/11 5:52 PM, Jonas Sicking wrote:
>>>>
>>>> On Tue, Aug 30, 2011 at 3:26 PM, Charles Pritchard<chuck@jumis.com>
>>>>  wrote:
>>>>
>>>>> On 8/24/2011 11:56 PM, Charles Pritchard wrote:
>>>>>
>>>>>> On 8/24/11 11:36 PM, Jonas Sicking wrote:
>>>>>>
>>>>>>> On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchard<chuck@jumis.com>
>>>>>>>  wrote:
>>>>>>>
>>>>>>>>>> Prpoposed:
>>>>>>>>>>
>>>>>>>>>> FormData output with the x-www-form-urlencoded mime type:
>>>>>>>>>> formData.toUrlEncodedBlob(xhr.send)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>> [Supplemental] FormData
>>>>>>>> void toMultipartBlob(in callback)
>>>>>>>> void toUrlEncodedBlob(in callback)
>>>>>>>>
>>>>> ...
>>>>>
>>>>>> xhr.send(formData) would be the same as:
>>>>>> formData.toMultipartBlob(function(blob) { xhr.send(blob); });
>>>>>>
>>>>>>
>>>>> Google's Picasa, and various other web apis accept multipart/related
>>>>> input.
>>>>> Given that we don't want a method for each output type supported, I
>>>>> think
>>>>> a
>>>>> generic method would better serve authors.
>>>>>
>>>>> [Supplemental] FormData
>>>>>  void toBlob(in FileCallback, in optional DOMString type, in any...
>>>>> args);
>>>>>
>>>>> The default type for FormData would be multipart/form-data.
>>>>> Vendors would be encouraged to support these, in addition:
>>>>> application/x-www-form-urlencoded
>>>>> multipart/related
>>>>>
>>>> What is multipart/related? Is that something supported by browsers? It
>>>> doesn't appear supported by gecko, and it's certainly not supported
>>>> for form submission in Gecko.
>>>>
>>>>
>>> No, it's not supported by browser forms.
>>>
>>> I'm trying to extend the FormData object, because it's a handy object for
>>> building up POST types used with XHR.
>>> Since FormData supports Blob append, it'd be nice to support the various
>>> services that use types other than multipart/form-data.
>>>
>>> Currently, FormData is all or nothing... so when interfacing with various
>>> web services, I have to go back to re-creating the mime message from
>>> scratch. Not a big deal, but it's frustrating to recreate the FormData
>>> interface over-and over again.
>>>
>>> This could be easy, with an extended FormData:
>>>
>>> http://code.google.com/apis/picasaweb/docs/2.0/developers_guide_protocol.html#PostPhotos
>>>
>>> var n = new FormData(); n.append(blob)...; n.toBlob(function(message) {
>>> xhr.send(message); });
>>
>> It would make sense to me to add a getAsBlob function to FormData. We
>> could also add support for other types of encodings than
>> "multipart/form-data", either by using separate functions, or by using
>> arguments to functions.
>>
>> However in all cases it seems much simpler to simply use return values
>> rather than callbacks.
>>
>
> Encoding of a large blob might be a slow process, relative to the normal
> event loop.
>
> multipart/form-data is a good place to start.
>
> Simple case:
> var callback = function(blob) { xhr.send(blob); };
> formData.toBlob(callback, 'multipart/form-data');
>
> Several services require signed messages in the http header, the scripting
> environment needs access to the blob data in order to sign the message body.

Neither multipart/form-data nor application/x-www-form-urlencoded
encoding is not slow, so there should be no need to make this an
asynchronous callback.

/ Jonas

Received on Wednesday, 31 August 2011 16:49:46 UTC