Re: File API Feedback

The BlobBuilder.append() method is central to the use-case I'm referring to.
builder.append(string data that comprises the multipart/form-data header);
builder.append(string data that comprises simple text part);
builder.append(string data that comprises the start of a binary part);
builder.append(fileBlob); // the file itself
builder.append(string data that closes the binary part);
// perhaps more binary and text parts
builder.append(string data that closes the multipart/form-data);
multipartBlob = builder.getAsBlob();

httpRequest.send(multipartBlob);

> For now, can a byte-ranged splice method defined on FileData (to
asynchronously create "ranged" FileData objects) satisfy your use case?

Splice doesn't come into play for the use case described above. The
motivation for the .splice method is to "chunk" very large files into many
parts, and to upload them individually... think large YouTube videos, where
an upload craps out after 80% has been done... you end up with nothing. By
splicing and uploading in smaller bites, the app is free to implement a
strategy where its not all-or-nothing. If any individual chunk fails, resend
that chunk.



On Tue, Jul 21, 2009 at 3:44 PM, Arun Ranganathan <arun@mozilla.com> wrote:

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