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.
