Re: New FileAPI Draft | was Re: FileAPI feedback

Dmitry,


> 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