Re: The most basic File API use case

On Mon, Dec 7, 2009 at 9:46 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

+1.

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

Agreed: start simple and then extend later.  I lean toward an input
element that requires a user action to bring up the dialog box, but
I'm still thinking about it.

> 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 Wednesday, 9 December 2009 21:32:01 UTC