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

Re: File API Feedback

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Sat, 27 Jun 2009 14:30:19 -0700
Message-ID: <c9e12660906271430n7ead1ee3j6a98e5293d75063a@mail.gmail.com>
To: arun@mozilla.com
Cc: Boris Zbarsky <bzbarsky@mit.edu>, Ian Hickson <ian@hixie.ch>, Anne van Kesteren <annevk@opera.com>, WebApps WG <public-webapps@w3.org>
On Thu, Jun 18, 2009 at 6:13 PM, Arun Ranganathan<arun@mozilla.com> 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).

Why does the URI contain the date "2006"? I feel like I'm viewing an
old document. Clicking on the link labelled "latest public version", I

The document at that address contains nothing about URI or URL. In
fact, it has an old date, 2006. Strangely, the "dev" document at the
"/2006" path has a date in the document "2009".

In the "latest public version" there is no getAsDataURI, nor a
getDataAsURL. I don't see "url" in the page anywhere.

As written, it seems like a synchronous method call. I recall
discussions where a few problems with synchronous design mentioned and
an asynchronous call was deemed the better approach.


There ought to be a mechanism by which the data is read, and an
announcement when that read is complete. Also progress events should
be supported on that.

In the old "dev" uri, I see the kludge:-

void getAsDataURI(in FileAsText callback, [Optional] in
FileErrorCallback errorCallback);

Can I ask why you've chosen to have the callee invoking callback
methods? What about extensibility? To add a progress event, you'd have
to pass in an optional "progress" callback, update the entire API.
Then a "complete" callback?

The "callback" arguments ought to be designed as events. The calling
context first subscribes to events, then requests file object to
perform the read.

DOM Events is the event API that we have and an event API ought to be
used. Callback dom properties would be another option to consider in
tandem, e.g. myFile.onprogress.

Received on Saturday, 27 June 2009 21:31:00 UTC

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