Re: File API Feedback

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*

Received on Monday, 29 June 2009 18:14:44 UTC