Re: First stab at File Writer

On Mon, Dec 7, 2009 at 7:46 AM, Robin Berjon <robin@robineko.com> wrote:
> Eric,
>
> On Dec 4, 2009, at 06:43 , Eric Uhrhane wrote:
>> Your FileWriter combines two things: building a blob of data and
>> saving it out to disk.  I like each of those individually, but I think
>> we should separate the parts for ease of reuse.  If a FileWriter just
>> took a Blob and wrote it out, then all BlobBuilder methods and the
>> Blobs they produced could be used elsewhere without your having to
>> implement them on FileWriter as well.  Peter O. Ussuri posted
>> something along those lines a couple of weeks ago [1], and Jonas [2]
>> and others have said similar things.  I like a lot of your pieces, but
>> prefer their decomposition.
>
> Yes, I'm participating in WebApps as well. It's annoying that this conversation straddles both group.
>
> I'm happy with decomposition as well and will spec it out one way or another. I've pinged the other thread with questions to try to hash out a few small details.
>
>> In 3.3: The mention of the checkbox as a potential way to indicate to
>> the user that the file's being selected for writing seems likely to
>> cause confusion.  A checked box could mean "this is granting write
>> access in addition to the normal read access", when we actually want
>> to express "this is granting write access only".  I realize this is
>> just an example, but it would be clearer to have e.g. a big "Save As"
>> instead of the traditional "Load".
>
> Actually, this depends on whether you're just saving or enabling a read-write open. As it happens I was thinking of the latter. But I agree and I'm not 100% convinced by the checkbox thing either (mostly I'm concerned that it would be too easy for users to miss).

I think you're right about that.  I favor a strict
read-only/write-only split for files selected by browsing.

>> In 3.3: ''This is not necessarily very elegant. Another option would
>> be to not touch input at all, and in order to address the use case of
>> loading a file to be saved provide variants of textWriter and
>> binaryWriter that could take the file object and go through the
>> download prompting defaulting to that file being selected, with the
>> "Careful you're going to overwrite" well-known platform prompt. It
>> would likely render the name and mediaType parameters useless.'
>>
>> Where do you get the file object?  From a previous save?  Or are you
>> using a file previously selected for reading, and now trying to save
>> back to it?
>
> You get the file from input in the usual way that the File API describes. Quickly (without error checking and all), you'd have:
>
>  <input type='file' onchange='loadFile()'/>
>
> and
>
>  function loadFile () {
>    var file = this.files[0];
>  }
>
> Now you have a read-only file in 'file'. The suggestion in the text above is that you'd make it writeable with:
>
>  function successCB (tw) {
>    // do something to manipulate the file
>  }
>  navigator.device.textWriter(file, successCB);
>
> This is similar to what we currently have:
>
>  navigator.device.textWriter("text/plain", sucCB, "dahut.txt", { endings: "crlf" }, errCB);
>
> Except that you don't need to provide the media type and suggested name. The user is prompted for a download (as usual) and upon accepting with a "Save As..." dialog. The only difference is that the dialog would have the provided file selected by default.
>
> Am I clearer? Maybe this would be easier to communicate with fake screenshots.

Clearer, but I don't like the idea of taking a read-only file and
making it writable.  I think reading and writing have very different
security concerns, so I'd like not to make it too easy to let the
browser suggest where to put files.  Let's have
browse-for-a-file-to-load and browse-for-a-file-to-save in the first
cut of this API, and then we can think about read-write stuff.  The
more liberal access we allow to stuff outside of a sandbox, the
hairier the security issues, and  the longer it'll take to get a solid
draft out.

>> In 2.1: "Do we need async writers? There are further details about
>> options for this below."
>>
>> Yes.  I think we should have an interface similar to Arun's, including
>> the progress events.  Writing out very large files, possibly over a
>> network, could take a really long time.  I think the synchronous
>> interface is best kept to worker context only.  Methods used to build
>> the blob probably need not be async.
>
> Right, I've been coming to the same conclusion, especially since several people have mentioned interest in using this API as an abstraction over writing files back to the cloud.
>
>> In 2.1: "Do we need a way to remove chars/bytes from the middle of a
>> file without rewriting it completely?"
>>
>> If your FileWriter can write out a Blob, you can slice the Blob
>> however you please before you write it.  This also leave UAs in
>> control of whether they want to keep Blob contents in memory or cached
>> on disk, rather than specifying implementation as is done in section
>> 3.1.
>
> Right, but before I go ahead and specify that out I'd like to know if implementers feel it is reasonable to keep writing to the file after it's been "downloaded". If yes, then I'd like to make that possible; if not I think the API might be a bit simpler.
>
> Either way I will update by FooWriters to be FooBuilders, and I think provide a saveTo(file).
>
>>> It lists a number of issues which I'm still mulling over. I also need to fill out the section that looks into cut-paste/drag-drop.
>>
>> If a drag-out operation could produce an event bearing a FileWriter,
>> such that the two writing mechanisms were pretty much identical to
>> use, that would be great.
>
> That was the idea I had discussed with Jonas. I'm looking into it.
>
>>  I'm not sure how cut+paste would interact
>> with files directly; wouldn't you access to the clipboard to be
>> orthogonal to access to files?
>
> Cut-paste and drag-drop are very similar; in general the more one can see them as different ways of performing the same operation the better IMHO. In general the system paste buffer can contain a file (or several), or media type annotated content. It's not a priority use case but I'd like the integration to be fleshed out. If it turns out to be too complicated, it can go in another spec.

Ah, I see; I was thinking about pasting data, not files.  Yes, I agree.

Received on Wednesday, 9 December 2009 23:30:03 UTC