- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Sat, 27 Jun 2009 14:30:19 -0700
- 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). > http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml 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 see http://www.w3.org/TR/file-upload/ 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. http://www.w3.org/TR/file-upload/#dfn-getdataasstring 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. Garrett
Received on Saturday, 27 June 2009 21:31:00 UTC