W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: New FileAPI Draft | was Re: FileAPI feedback

From: Arun Ranganathan <arun@mozilla.com>
Date: Wed, 05 Aug 2009 15:14:48 -0500
Message-ID: <4A79E838.8020907@mozilla.com>
To: Dmitry Titov <dimich@chromium.org>
CC: Web Applications Working Group WG <public-webapps@w3.org>

> the spec lists a use case about a web app that needs to send file(s) to the
> server programmatically. I happen to think lately about an E-mail app that
> can send attachments. FileData and its splice() method are useful here. I
> assume the XHR2 spec would get XHR.send(FileData) method. XHR2 provides
> progress events.
Yes; I think in future, XHR2 will have an overloaded send method that 
can send a FileData object.
> - it'll need some way to save the File object to the Database field or a
> localStore value, so it can be stored there till uploaded by the worker or
> another page (I think this was discussed before, perhaps it's on the way
> into corresponding specs?) Of course, we don't want to write the content of
> the file into the Database, only opaquely roundtrip the 'file representing
> token'.
Currently, the only "file representing token" that this specification 
allows for is the filedata://[UUID] URL, which is spec'd to be 
shortlived.  Figuring out how to store file objects is a logical next 
step.  I'm keen for us all to agree on some set of requirements as a v1 
(and then release a FPWD), since the amount of "new feature" suggestions 
have been large (but very welcome ;-) ).
> - it'd be good to have the ability to 'snapshot' files. During the
> send/upload time the original files that user selected may 'disappear' from
> the locations captured. For example, they were photos on a flash card that
> got removed. It would be useful to (optionally) be able to make a copy of
> the file to some temporary location. This can be an async operation that
> comes back with a callback that gives a 'temp copy' File object
> (File.makeTemporaryCopy(callback)). Some limit on disk space could be set.
> They also will need to be removed at some point.
This is another interesting feature.  It seems unlikely that we'd all 
agree on a  standardized disk space limitation, but there could be 
another way to reason through this.

Again, I'm keen on shipping a v1 specification soon, and then iterating 
on it, either as part of this endeavor, or the Device API WG's File API 
(depending on how that shapes up).

-- A*
Received on Wednesday, 5 August 2009 20:15:31 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC