W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2009

RE: File API Feedback

From: Adrian Bateman <adrianba@microsoft.com>
Date: Thu, 18 Jun 2009 20:06:48 -0700
To: "arun@mozilla.com" <arun@mozilla.com>, Boris Zbarsky <bzbarsky@MIT.EDU>, Ian Hickson <ian@hixie.ch>
CC: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
Message-ID: <749F45FA745A3244A87A63316D4E26B187BCECB0A2@NA-EXMSG-C108.redmond.corp.microsoft.com>
On Thursday, June 18, 2009 6:13 PM, Arun Ranganathan wrote:
> Boris Zbarsky wrote:
> > Ian Hickson wrote:
> >> Local display of images before uploading them requires being able to
> >> take a File object and poke it into parts of the platform that
> >> currently only take URLs. I suggest that the way we address this is
> >> by adding an API to a File object that returns a URL like this:
> >>
> >>    scheme:uuid
> >
> > Can't one already get data out of a File object?  And if so, is there
> > a reason to not just have a way of getting a data: url representing
> > that data out of one?
> This can be done in existing versions of Firefox synchronously, and in
> the existing editor's draft asynchronously (via getAsDataURI which
> should be renamed).
> I think the original discussion about this (re-reading IRC notes) was
> to have a "short-lived" URL (as locator, not as a Base64 dump) in the
> scope of the script that actually referred to the file.  Upon reflection,
> Data URLs satisfy the use case for URLs to "... poke into parts of the
> platform that currently take only URLs."
> Hixie, I think a Base64 representation of the file resource may be
> sufficient, particularly for the image use case (which is how it is
> used already).  Can you flesh out why the new schema is a good idea?

I'd be concerned about the size. If you have a large file then exploding it into base64 just to copy it somewhere else into the platform where it will be decoded into yet another copy doesn't seem optimal. It may be a good v1 solution though.

Received on Friday, 19 June 2009 03:09:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:12:54 UTC