- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 31 Aug 2011 09:48:47 -0700
- To: Charles Pritchard <chuck@jumis.com>
- Cc: public-webapps@w3.org
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