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

Re: File API Feedback

From: Garrett Smith <dhtmlkitchen@gmail.com>
Date: Mon, 29 Jun 2009 23:52:06 -0700
Message-ID: <c9e12660906292352m7c9d6163uef2b9592f135633f@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 Mon, Jun 29, 2009 at 11:14 AM, Arun Ranganathan<arun@mozilla.com> wrote:
> Garrett,
>
> Thanks for taking the time to review this.
>
> Garrett Smith wrote:
>>
>> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
>> Why does the URI contain the date "2006"?
>
> It certainly is confusing, but the '2006' persists as an artifact of the CVS
> repository that I'm using to work on my editor's draft.  When ready, it
> should be published to a URL that is more intuitive (and follow how W3C
> usually publishes things).
>>
>> In the "latest public version" there is no getAsDataURI, nor a
>> getDataAsURL. I don't see "url" in the page anywhere.
>>
>>
>
> This is added to the editor's draft.
>>
>> 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.
>>
>
> Correct -- that is why the editor's draft reflects that discussion by
> formulating useful APIs as asynchronous ones.
>>
>> 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.
>>
>>
>
> Callbacks are used so that these APIs can behave asynchronously.  As drafted
> now, I agree that it is a kludge because the use the error callback is made
> optional.  I no longer think it should be optional, and implementations MUST
> call one or the other.  The 'null' File data string (or a null FileList) is
> not as instructive as simply having an error callback.
>

That design limits the number of callbacks to one. That one callback
can only be added in the invocation to read.

Instead, allow multiple callbacks to be added with the DOM Events API:

// Add some callbacks
fileObject.addEventListener("complete", readComplete, false);
fileObject.addEventListener("error", readError, false);
fileObject.addEventListener("success", readSuccess, false);

fileObject.getDataAsText();

An asynchronous file read is like an asynchronous XHR, in a way.

> However, I disagree that an event model is necessary for *this*
> specification.  Certainly, ProgressEvents can be used with *other* aspects
> of the platform, in conjunction with the File API.  They are not necessary
> for asynchronous file data accessors.
>

Lets back up and consider why one might want Events, or why Events make sense.

Events decouple the call to "read" from the notification that the
object is done reading. That allows the File object, "read" method,
and its events, to evolve over time. Decoupling messaging (callbacks)
from commands (behavior) enables independent and concurrently existing
views (interfaces) of the API.

The two ways to implement events are:
1) DOM Events - works and is widely implemented in major browsers.
2) DOM Event handler properties work and even more widely implemented and used

AISB, Events decouple the read from the notification. N callbacks can
be attached, removed, at any time, and the reading can be wrapped in
code that exists elsewhere. This makes for writing cleaner
implementation code. Inelegant APIs proliferate bad design. The
current browser APIs followed by the burgeoning "Ajax" libraries might
be considered an example of such causality.

Progress-type Events are useful because the API is asynchronous.
What if reading the file times out?

If an entire directory is uploaded, as in the Picasa-style example,
when does the "success" callback fire?
1) after all files in "stress" are successfully read
2) upon completion of each file

When reading one large file (a movie, for example), how will the
program provide notification of progress of the upload?

Garrett
Received on Tuesday, 30 June 2009 06:52:47 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:31 GMT