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

Re: File API Feedback

From: Arun Ranganathan <arun@mozilla.com>
Date: Tue, 21 Jul 2009 15:44:19 -0700
Message-ID: <4A6644C3.9060500@mozilla.com>
To: Michael Nordman <michaeln@google.com>
CC: public-webapps@w3.org
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT