On 8/31/2011 10:19 AM, Glenn Maynard wrote:
On Wed, Aug 31, 2011 at 12:48 PM, Jonas Sicking <jo...@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.
