Re: [XHR2] Blobs, names and FormData

On 8/31/2011 10:19 AM, Glenn Maynard wrote:
> On Wed, Aug 31, 2011 at 12:48 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>
>     > 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.
>
>
> Sorry if this doesn't make sense as I havn't been following this 
> closely enough, but if the form contains a file, this will cause the 
> file to be read from disk immediately, creating the encoded blob in 
> memory, right?  If it may trigger I/O, it should be async, regardless 
> of how expensive the operation performed on the resulting data might be.
>
> (It may be possible for implementations to create a Blob class that 
> generates the encoded form-data on demand, as async reads happen later 
> on.  But, even if that's possible for form-data, it won't necessarily 
> be for other possible types passed to toBlob, eg. x-www-form-urlencoded.)

That sounds correct. Yes, a very large blob file, x-www-form-urlencoded 
would have to be
read through to determine the output blob size. I agree, that 
specialized Blob classes could cut-down/delay
memory copies.