- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 18 Jul 2011 12:23:17 -0700
- 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 UTC