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, 11 Jul 2011 12:46:23 -0700
Message-Id: <F07E3468-0E0F-4A41-800B-BD34FDD37E93@jumis.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>
To: Adrian Bateman <adrianba@microsoft.com>
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?
> 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.

Received on Monday, 11 July 2011 19:47:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:22 UTC