Re: File API Feedback

Michael Nordman wrote:
> http://code.google.com/apis/gears/api_blobbuilder.html
>
>   
>> 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