Re: File API Feedback

Michael Nordman wrote:
>> This I'm less sanguine about, since the immediately desired capability is>
> to work with existing system files.

> The motivating usecase for this feature in Gears is to compose the body of a
> POST in the multipart/form-data format, including binary file parts. The
> resulting blobs can then be uploaded with HttpRequest. For example, Gmail
> uses this when sending/saving messages with attachments that had been queued
> for delivery while offline.
Currently, the methods defined on the FileData interface in the FileAPI 
specification do not provide the ability to generate chunks of binary 
data within script, which can then be appended to a FileData object.  
Also, we need more discussion around storing FileData objects (files) 
between sessions.  Right now we have on the table a URL that refers to 
files that is short lived, and a method that splices a FileData object 
asynchronously (with offset and length).  These haven't been added to 
the draft that's in circulation, but I hope to add them shortly.

I'd like to make sure I understand your use case.

If an attachment is queued already, doesn't Blob.slice(offset, length) 
generate *new* Blobs from that data, which can in turn be used with 
HttpRequest?  It seems that you need:

void append(data) (defined on BlobBuilder)

to extract "data" from storage and then append it to any other Blob, and 
then call getAsBlob() (defined on BlobBuilder) to coin a new Blob, with 
the new data appended. 

For now, can a byte-ranged splice method defined on FileData (to 
asynchronously create "ranged" FileData objects) satisfy your use case?  
That way, we can discuss file data persistence a bit more, and work on 
this in another edition of the specification. 

I'll report back with a draft.

-- A*

Received on Tuesday, 21 July 2009 22:45:01 UTC