W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [FileAPI] FileWriter and read-only files

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 11 Apr 2011 17:12:20 -0400
Message-ID: <BANLkTimx6pPFTMY+2eSGdPB=g3_KK37dxw@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>
Cc: public-webapps@w3.org
On Mon, Apr 11, 2011 at 4:22 PM, Eric Uhrhane <ericu@google.com> wrote:

> Are you thinking of FileEntry?  File objects are always immutable, and
> there's currently no way to get from a File to a FileWriter.
>

I'm thinking of File, but I didn't notice that there's no FileWriter(File)
constructor.

I suppose the answer, in this case, would be something like adding a
createWriter method to the objects in the HTMLInputElement.files array (a
new subclass of File), to create a writer for the underlying file.  In that
case, there's no need for an additional readOnly property: if you don't have
permission to write to the file then the list item would just be a File,
with no createWriter method.

As an aside: I don't understand File being immutable.  The underlying file
on disk isn't; it may change between the user selecting it with <input> and
the script reading it.  Browsers don't read the entire contents of files
before exposing them in input.files, of course.  What's supposed to happen
here?  It seems like File is trying to act like an immutable Blob, but doing
so by referencing a resource that isn't.

> opening files for write.  For example, <input type=file file=write> to ask
> > for write permission (setting readOnly if only read permission was
> granted,
> > eg. with an "open read-only" checkbox), and <input type=file file=create>
> to
> > also ask the browser to show a "Save As" dialog instead of an "Open"
> dialog.
>
> > Later, it would be good to also have an attribute on <input> to allow
> We discussed this a while back, and people generally preferred
> something like FileSaver instead of markup.
>

FileSaver only works if you're writing an entire file; it doesn't allow
updating or appending to an existing file.  Handling these cases is the very
reason FileWriter exists in the first place, isn't it?

It's also not ideal for writing very large files.  Although nothing requires
browsers keep Blobs in memory (they can, and probably should, scratch to
disk for very large blobs), if you're writing several gigabytes of data,
that implies doubling disk access and storage, as the data is copied from
temporary storage to the target file.

It seems asymmetric that we can open and read with <input> and FileReader,
but we can't do the same for writing with <input> and FileWriter.  I
understand if this isn't something to do just yet, but I hope it won't be
written off entirely.

-- 
Glenn Maynard
Received on Monday, 11 April 2011 21:12:48 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:44 GMT