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! -Charles On Jul 11, 2011, at 12:21 PM, Adrian Bateman <adria...@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? > > Sent from my Windows Phone > From: Charles Pritchard > Sent: 11-Jul-11 12:03 PM > To: Adrian Bateman > Cc: Jonas Sicking; Anne van Kesteren; Julian Reschke; Alfonso MartÃnez de > Lizarrondo; Webapps WG > Subject: Re: [XHR2] Blobs, names and FormData > > getFile could work with dataTransfer for dropping files onto the desktop. > There may be other Apis which work with File but not with Blob, or not as > well with Blob. > > Blob already requires linking/abstraction from createObjectUrl. Internally, > getFile could simply run createObjectUrl and treat it as a named file. I > doubt this would require much additional work from implementers. > > > -Charles > > > > On Jul 11, 2011, at 11:00 AM, Adrian Bateman <adria...@microsoft.com> wrote: > > > On 11 July 2011 10:53, Jonas Sicking wrote: > > On Mon, Jul 11, 2011 at 10:12 AM, Adrian Bateman <adria...@microsoft.com> > > wrote: > >>> Some content management systems use the original filename by default > >>> when storing files in document libraries. It's certainly a lesser use case > >>> but seems like a relatively trivial change to the API. I don't see it as > >>> sugar, since it's not possible to achieve this on the client in any other > >>> way. > >> > >> I've proposed adding the following function to BlobBuilder: > >> > >> interface BlobBuilder { > >> ... > >> File getFile(in DOMString name, [optional] in DOMString contentType) > >> ... > >> }; > >> > >> This will let you accomplish the same thing in just 2 additional lines > >> of javascript (one of which can be reused). > > > > Well, yes, there are multiple ways of proposing a solution. My point was > > there is no easy way to do this without adding some functionality somewhere > > (I don't consider manually constructing a multi-part message a simple > > approach). I don't like the BlobBuilder solution because it adds the notion > > of needing to link the same underlying blob data to both a Blob and File, > > which suggests an extra level of abstraction in the implementation. I'm not > > sure what other use case there is for getFile and I prefer the more > > isolated simpler fix to FormData. >