Re: First stab at File Writer

Robin:

Thanks for getting this going.  Comments inline.

On Thu, Dec 3, 2009 at 9:47 AM, Robin Berjon <robin@robineko.com> wrote:
> Hi,
>
> I just checked in a first stab at File Writer. Nothing definitive of course, don't scream if you don't like it (but do provide feedback!).
>
> You can find it at:
>
>  http://dev.w3.org/2009/dap/file-system/file-writer.html

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.

Smaller things:

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

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?

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.

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.

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

> If you don't have time to read all the details, at the very least I'd appreciate feedback and input on the security aspects.
>
> Before anyone complains that it doesn't address all the file system use cases: that's by design, you also need the file navigation API for that (which will also provide its own ways of creating writers). Of course, you also need the WebApps File API.
>
> Fire at will!
>
> --
> Robin Berjon
>  robineko — hired gun, higher standards
>  http://robineko.com/

      Eric Uhrhane

[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0929.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0225.html

Received on Friday, 4 December 2009 05:44:45 UTC