Re: The most basic File API use case

Peter:

     Thanks for sending this and the previous email.  I'm sorry about
the slow response; it arrived just as I went away on holiday.

On Mon, Nov 23, 2009 at 6:34 AM, Peter O. Ussuri <ussuri@threetags.com> wrote:
>>> The current File API draft lets a web app to read the file, but there
>>> seems
>>> to be no easy way for a web app to construct an arbitrary binary file and
>>> trigger a SaveAs/download dialog, with the file name suggested by the
>>> app.
>>>
>>
>> I agree with this use case being a logical next step.
>>>
>>
>> As far as Group 0 goes, I agree and think we'll need:
>>
>> 1. A script initiated SaveAs mechanism.
>>
>> 2. Something like BlobBuilder (as you point out).
>>
>> Next steps can evolve from these.

+1

> May I suggest then a specific implementation, in order to move the process
> forward a bit. All names/signatures/behaviors below are intended to start
> the discussion only, and not as a draft or anything formal. :)
>
> Based on [1] and [2], we can have two interfaces introduced into the File
> API specification:
> BlobBuilder: based on Google Gears [2].
> interface BlobBuilder {
>     void appendText( in DOMString text, [Optional] in DOMString encoding );
>     void appendBinaryString( in DOMString text ); /* same as in FileReader
> */
>     void appendByte( in long val ); /* if val is not in the [0-255] range,
> throws an exception */
>     void appendBlob( in Blob blob );
>     /* this method can probably be asynchronous, but IMHO this is not
> necessary at the "Group 0 use case" stage */
>     Blob getBlob();
> }
> FileWriter:
> interface FileWriter {
>     /* shows the SaveAs dialog, returns the saved File or null if
> error/canceled by the user */
>     /* can be made synchronous (modal) or asynchronous, I'm not sure at the
> moment which approach is better  */
>     File saveBlobAsFilePrompt( in Blob blob, in [Optional] DOMString
> suggestedFileName ); /* synchronous/modal variant; asynchronous will return
> nothing and have events */
> }
> Later FileWriter can be expanded to cover other use cases.
> Thanks,
> Peter
> [1] http://www.w3.org/TR/2009/WD-FileAPI-20091117/
> [2] http://code.google.com/apis/gears/api_blobbuilder.html

I like the BlobBuilder vs. FileWriter split.  I'd prefer an HTML
element to something that could pop up a modal dialog, though.  Robin
Berjon has just posted [1] a draft that handles that part nicely,
though he combines building and writing into a single interface.

The pieces I'd like to see implemented separately are:
1) Some way of obtaining a FileWriter [likely via an input element
that spawns a dialog box].
2) Some way of building a Blob [your BlobBuilder or what Maciej's [2]
been talking about].
3) A way to write the Blob [no matter where it came from] to the FileWriter.

     Eric Uhrhane

[1] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0113.html
[2] http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html

Received on Friday, 4 December 2009 05:58:42 UTC