Re: The most basic File API use case

On Mon, Dec 7, 2009 at 1:51 PM, Peter O. Ussuri <ussuri@threetags.com> wrote:
> Hi Robin,
> Thanks for your response!
>
>> 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.
>
> Fair point - playing with encoding(s) is probably not the right place here.
> We thus can have just a binary builder and leave text/strings out of the
> 'building' process altogether. FileWriter can be instructed later to
> write/save either a blob or a string.
>
>>
>> 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?
>
> The main reason I introduced the "group 0" use case was to make sure a
> 'minimal' API is agreed upon and implemented by browser vendors, so that
> developers like myself could start using it. Thus if "a proposal for binary
> data in ES" is nowhere near stability (I can't tell), I suggest a simple
> binaryBuilder/blobBuilder interface is introduced to move things forward.
> If, on the other hand, there is an alternative way to construct binary data,
> then of course we should use it and should not create a separate
> binaryBuilder just for File API. There should be alignment with FileReader,
> though, and FileReader API already specifies blobs, so BlobBuilder does not
> look redundant at first glance.

My suggestion would be to create a BlobBuilder for now that didn't
include methods for BinaryArray (or whatever it'll be called)
arguments for now. And just add them once we feel that a spec is
stable enough for it.

> Regarding "continuous writing": I agree that there are use cases that would
> benefit a lot from it, so the behavior should be specified and implemented
> in some way down the road. However, as you point it out yourself, there are
> some open issues to be clarified/resolved around it. Thus my suggestion
> would be to design FileWriter in a way that would keep the continuous
> writing option "on the table", but have a "write-and-done" method specified
> now, so that vendors can implement it.

I have the same reaction. An API that would allow simply bringing up a
"safe file as" dialog, similar to the dialog used when downloading
files, is something that I know we could implement in Firefox right
away.

A "continuous writing" API is something we'd have to develop new
security models for, in order to get the user to understand what is
happening. Thus I have no idea when or if we'd be able to do that.
It's certainly something I'd encourage people to research and think
about, but it's something I'd rather not bundle with the simpler API
spec-wise.

> To summarize, my preference would be to have a very basic/simple FileWriter
> API agreed upon and implemented sooner, and have a more
> advanced/sophisticated API added on top of than later.

Agreed.

/ Jonas

Received on Tuesday, 8 December 2009 05:47:52 UTC