Re: File API to separate reading from files

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*

Received on Tuesday, 1 September 2009 04:51:43 UTC