Re: New FileAPI Draft | was Re: FileAPI feedback

Hi,

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.

However, it seems some additional functionality is needed. For example, when
sending e-mail with attachments, it may be good to 'release' the UI as soon
as possible and have some sort of "Outbox" model when outgoing email and
attachments are sent in the background, while user can close the page or
navigate away, in which case the send could be resuming later when the app's
page is open again - but it would be really bad to loose the unsent email.

This is what comes to mind:

- 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'.

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

Dmitry



On Tue, Aug 4, 2009 at 6:55 PM, Arun Ranganathan <arun@mozilla.com> wrote:

> I have updated the draft of the File API, and welcome more review.  Note
> that it is no longer called "FileUpload" since this term has become
> misleading.
>
> In particular, here are some of the issues addressed (and some not):
>
> > Any reason you're using an XHTML file to edit this?  Also, the
> indentation is awkward.
>
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
>
> > For what concerns the "file as URI" feature:
> >What about reusing the "cid" scheme?
>
> After having looked at the RFCs for cid and mid schemes, I don't think the
> cid scheme is appropriate for our use case, since it is tightly tied to the
> notion of message body, which isn't necessarily true in all cases of file
> data.
>
> I have a proposal in this draft for the "file as URL" proposal (originally
> broached in IRC, but which has seen some discussion on the listserv).  I'd
> welcome feedback on it, especially the processing model for these URLs.  A
> simple ABNF using UUIDs as unique identifiers has been proposed here.
>
> > File API should probably have some way to get only parts of the file.
>
> This has been added as a new method.  Feedback welcome!
>
> >[The existing design] limits the number of callbacks to one. That one
> callback
> >can only be added in the invocation to read.
> >Instead, allow multiple callbacks to be added with the DOM Events API
>
> While this was an intriguing suggestion (and seemed like it was a more
> powerful programming model), I wasn't convinced that it was needed for the
> File API.  It did lead to a more complicated model that didn't seem to fully
> justify the power.  However, I did study subsequent use cases, and
> eliminated error callbacks, allowing callbacks themselves to handle error
> conditions.  Also, I introduced a cancelReads( ) which can be used with
> timeouts.  I'm not convinced that an event model is necessary for
> asynchronous data accessors on file data; DOM events aren't useful in all
> cases.  It's also worth nothing that the File API in general may be subject
> to further iteration in the Device API WG, which may introduce notions of
> "write" APIs.
>
> >Note of course that whatever API supports ranges needs to ensure that
> >the data isn't forcibly coerced into valid Unicode, as the underlying
> >data for an image can include all sorts of patterns which aren't valid
> >UTF8/16/....
>
> It was clear that getAsText was insufficient, so more asynchronous data
> accessor methods have been added.
>
> > I think FileDialog is a bad idea. We already have UI for selecting
> multiple files: <input type=file
> >multiple>.
>
> This has now been eliminated from this draft.  I'm keen to move towards
> fpwd, and it seemed that FileDialog was needlessly controversial.  I think
> it still is useful, and think it could be added later.
>
> -- A*
>
>