RE: [XHR2] Blobs, names and FormData

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 <adrianba@microsoft.com> wrote:

> On 11 July 2011 10:53, Jonas Sicking wrote:
> On Mon, Jul 11, 2011 at 10:12 AM, Adrian Bateman <adrianba@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.