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

Re: File API Feedback

From: Arun Ranganathan <arun@mozilla.com>
Date: Thu, 18 Jun 2009 18:13:05 -0700
Message-ID: <4A3AE621.4090202@mozilla.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>, Ian Hickson <ian@hixie.ch>
CC: Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
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?

-- A*
Received on Friday, 19 June 2009 01:13:43 UTC

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