W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [XHR2] Blobs, names and FormData

From: Michael Nordman <michaeln@google.com>
Date: Mon, 18 Jul 2011 12:52:00 -0700
Message-ID: <CAHpoE=iqVOJGOumyATdn6hbxoE-1mawBgwWGFn4_uMdje4v+CA@mail.gmail.com>
To: Adrian Bateman <adrianba@microsoft.com>
Cc: Charles Pritchard <chuck@jumis.com>, Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>, Julian Reschke <julian.reschke@gmx.de>, Alfonso Martínez de Lizarrondo <amla70@gmail.com>, Webapps WG <public-webapps@w3.org>
The problem is around naming the binary parts attached to
multi-part-form-encoded FormData. I think I'm in favor of the more  direct
solution to this problem, providing a FormData.append() variant that
optionally  allows the caller to specify a name. If no name is provided and
the blob is a File, the filename is used, otherwise a non-empty value
generated by  the client is used.

  formdata.append("elementName", blob, "picture.png");

BlobBuilder.getFile() as a solution to this particular problem is less
direct (and less obvious and less discoverable so less friendly). And it
raises questions like... Is the blob data really flattened out as a file on
the disk somewhere? If not, then getFile() is somewhat misleading. Is so, we
may have to create actual files when we otherwise wouldn't. Where is this
file created? When does it get deleted?

2011/7/18 Adrian Bateman <adrianba@microsoft.com>

> On Monday, July 11, 2011 12:46 PM, Charles Pritchard wrote:
> > Problem is too strong a statement. I am all for trivial changes, part of
> my
> > advocacy for getFile is from past experiences when blob was less
> supported;
> > getFile would have helped.
> >
> > FileReader has base64 encoding for binary data-- base64 encoding
> otherwise
> > only works on DOMString.
> >
> > I'd like to see both proposals implemented... Then I get everything!
> > On Jul 11, 2011, at 12:21 PM, Adrian Bateman <adrianba@microsoft.com>
> wrote:
> > > It requires more work for us. Our createObjectURL doesn't require that
> abstraction.
> > > The difference here is in the ECMAScript type. In contrast, modifying
> FormData
> > > append is a trivial change.
> > >
> > > What are the other APIs where this is a problem?
> Our view is to see everything here as a Blob. A File is a specialisation of
> Blob that
> happens to have a name and modified date. If there is an API that replies
> on File to
> work correctly we think we should fix it to work with Blob. For example,
> FileReader is
> really BlobReader and works fine with Blobs. To me, getFile() should be
> unnecessary and
> the best fix for FormData is to just modify append for this situation.

> Adrian.
Received on Monday, 18 July 2011 19:52:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC