Re: The most basic File API use case

Hi Peter,

On Nov 23, 2009, at 15:34 , Peter O. Ussuri wrote:
> 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. :)

Thanks for your suggestions, they're definitely very useful. As Eric pointed out I dumped the content of my own brain over at http://dev.w3.org/2009/dap/file-system/file-writer.html. I was aware of your proposal before I did so but I found it easier to write my ideas beforehand — small head I have :)

I think we should merge our ideas, some notes below.

> 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(); 
> }

Opera's original file system API also had encoding as part of its call that wrote out text — I think that's a bad idea. If you create a text file/blob, you probably really want all of it to use the same encoding. Allowing it to be specified on all calls is begging for bugs. I think that configuring a builder/writer with that once is safer.

I'm not adverse to appendBinaryString/appendByte but I was sort of hoping that a proposal for binary data in ES would stabilise quickly and that we could just appendBinary(binaryThingie).

Apart from these small details I think that the primary distinction between our approaches stems from whether we consider it possible to keep writing to a file after it's been "downloaded". I think that there are use cases to allow that, but I equally understand if implementers see it as going somewhat out of the regular download situation and may get anxious about the implication that that might have (which it why I discuss that in my security section, and produced the save/close dichotomy, which I'm not sure I'm entirely happy about).

The sort of usage I have in case for continuous writing is 1) load a document (of any kind, possibly big) for editing in your browser; 2) tweak it; 3) save; 4) view it in another application; 5) decide to tweak it some more. A more concrete example could be a browser-based POV editor using WebGL niftiness, and doing renders outside using the POV engine. Without continuous write step (3) involves the download dialog, the file picker, "are you sure you want to replace this file" prompt at each tweak — it's a usability PITA.

I would tend to think that continuous write is not so different from downloading a file without Content-Length — but I'd like some feedback on that.

If implementers agree that continuous write is doable, I think we should keep it and from there my proposal to merge our proposals would be to take my draft, turn the BinaryWriter and TextWriter into Binary/TextBlobBuilder equivalents, and provide a way to tie a Blob to a downloaded file. Blobs and File are already linked, so essentially it could just be about adding a flag, or specifying your saveBlobAsFilePrompt to stay manipulatable after save.

WDYT?

-- 
Robin Berjon - http://berjon.com/

Received on Monday, 7 December 2009 15:22:28 UTC