FileSystem compromise spec

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?

I'd like to hear from folks who are interested, but not in the current spec.

Thanks,

	Eric

Received on Friday, 16 November 2012 00:40:10 UTC