Re: The most basic File API use case

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.

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.

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.

Best regards,
Peter O.