On 11/15/12 7:39 PM, ext Eric U wrote:
As discussed at TPAC, there's little support for the current FileSystem API, but
some support for a new API, and I promised to put forth a compromise proposal.
In order to do that, I'd like to hear 1) what kinds of changes would make it
more popular; 2) who I'm trying to convince. There are a number of folks who
have said that they're not interested in a FileSystem API at all, so I'd rather
concentrate my efforts on those with skin in the game.
So far I've been hearing:
* It's too complicated. A number of the methods aren't absolutely necessary
if the user's willing to do a bit more work, so they should be dropped.
* Even for what functionality we keep, it could be simpler.
* The synchronous [worker-only] interface is superfluous. It's not necessary
for 1.0, and it's a lot of extra implementation work.
* It's designed to handle both the sandbox and the
outside-the-sandbox use cases. For folks interested in just the sandbox
and
no future expansions, that seems like wasted effort, and a sandbox-only API
could be simpler. It's not clear to me that there is anyone interested in
just the sandbox and no future expansions, but if there is, please speak
up.
I've certainly heard from folks with the opposite goal.
Does that sum it up?
That is a helpful summary so thanks for that.
Another at least somewhat related topic is the relationship between
WebApps' File* specs and the file specs in scope for SysApps and Adam
did a good job of clarifying that in
<http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0335.html>.
It seems like it would be useful to look at these various file and
database specs from a high level use case perspective (f.ex. "one way to
address UC X is to use spec X"). If anyone is aware of some related
docs, please let me know. Doug - wondering aloud here if this is
something webplatform.org might cover or if you know of someone that
might be interested in creating this type of documentation?
-Thanks, AB
I'd like to hear from folks who are interested, but not in the current spec.
Thanks,
Eric
