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.
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.
-- A*
