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

Re: [XHR2] Blobs, names and FormData

From: Charles Pritchard <chuck@jumis.com>
Date: Mon, 18 Jul 2011 12:23:17 -0700
Message-ID: <4E248825.3040007@jumis.com>
To: Adrian Bateman <adrianba@microsoft.com>
CC: 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>
On 7/18/2011 12:09 PM, Adrian Bateman wrote:
> 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.

In that case, I'd like to see the createObjectUrl semantic allow file 
names as well, so that we can have a nice
right-click+download option on anchors to those objects.

-Charles
Received on Monday, 18 July 2011 19:23:46 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:46 GMT