Ian Fette (イアンフェッティ) wrote:
I would like to make another plug for
http://dev.w3.org/2006/webapi/fileio/fileIO.htm
This had the notion of writing files, file streams, directories, and
being able to integrate into the host filesystem. All of these are
important for reasons I outlined in
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-August/022388.html
and subsequent replies.
Ian:
Nothing in my draft precludes those from coming later, in a v2 (and
subsequent iterations), modulo good proposals about platform differences
and security issues. Writing out data to the filesystem is a very
different set of issues, with different security issues. There are
numerous issues that need resolution here. It turns out the File API is
a controversial one, even to get right basic read features, and I'm keen
to finish a v1 draft soon. It's clear that even within the spectrum of
read, we may not quite satisfy all use cases (such as fseek) in v1, but
I'd like something that we can iterate on later. *Even* addressing the
use cases of reading data, we've encountered discussions about
programming style (Java I/O vs. a model closer to XHR), progress events,
etc. I'd like to resolve these in a v1 draft first.
I think v1 should address the most common use cases, which really do
appear to be:
"I
want to take some existing data and either put it into the cloud or
make it available offline".
Right, because we can't even do this elegantly on the web today!
Developers use Firefox's synchronous API for File access, or Gears, or
Flash (at least to get data from the file system into web apps and then
"the cloud"). Furthermore:
They don't really handle the use case of
"I want to create new data and save it to the local filesystem", or "I
want to modify existing data on the filesystem", or "I want to
maintain a virtual filesystem for my application, and potentially map
in the existing filesystem"
Not *yet* but I think that these features can be evolved over the course
of time. The proposal you cite:
http://dev.w3.org/2006/webapi/fileio/fileIO.htm
doesn't adequately address security issues, and deals with use cases
that I'm not so sure are critical for a first version. I appreciate
that Google wants these next, and so I'd like to see proposals that
address the open issues, some of which have been mentioned on the whatwg
thread you posted a link to.
I'm on vacation Sept. 1 - Sept. 4, so I'll respond to other email about
this topic upon my return.
-- A*
