Re: Moving File API: Directories and System API to Note track?

My personal objections (ones that I think are shared by at least some other Safari folks):

- It's way too complicated. (As one crude metric, I count 22 interfaces; and yes, I know many of those are callback interfaces or sync versions of interfaces; it still seems overengineered).
- I see value in the use case of a private sandboxed storage area, as staging for uploads, to hold downloaded resources, etc. But:
    - It's not totally clear to me why a filesystemlike API is the best way to serve these use cases, particularly if in practice it is actually backed by a database.
    - The API as designed is way too complex for just that use case.
- I'm not keen on exposing portions of the user's filesystem. In particular:
    - This seems like a potential security/social-engineering risk.
    - This use case seems more relevant to system apps based on Web technology than Web apps as such; I fear that system-app-motivated complexity is bloating the api.
    - Many of Apple's key target platforms don't even *have* a user-visible filesystem.
    - We'd like to keep Web APIs consistent between our various platforms consistent as much as possible.
    - I think trying to serve the "real filesystem" use cases adds a lot of complexity over the "private storage area" use case.
- We already have way too many storage APIs. To add another, the use cases would have to be overwhelmingly compelling, and highly impractical to serve by extending any of the other storage APIs (e.g. IndexedDB).
    - In particular, I have heard an explanation of why IndexedDB as it currently exists can't handle all the use cases for file-like storage, but I have heard no explanation of why it can't be extended in that direction.

For these reasons, I think it is unlikely that Safari would ever support Filesystem API in its current form. I could imagine considering a *much* narrower API, scoped only to the use case of private storage areas for Web apps, but only if a compelling case is made that there's no other way to serve that use case.

For what it's worth, even the DeviceStorage API proposal is too complex for my tastes, in its current iteration.

I think keeping the Filseystem API on the REC track in its current form is actively bad, because it leads outside observers to be misled about where the Web platform is going. For example,  sites like <http://html5test.com> give out "points" for it even though it seems unlikely to advance on the standards track as it stands today.

Regards,
Maciej

On Sep 21, 2012, at 4:32 PM, Eric U <ericu@google.com> wrote:

> While I don't see any other browsers showing interest in implementing
> the FileSystem API as currently specced, I do see Firefox coming
> around to the belief that a filesystem-style API is a good thing,
> hence their DeviceStorage API.  Rather than scrap the API that we've
> put 2 years of discussion and work into, why not work with us to
> evolve it to something you'd like more?  If you have objections to
> specific attributes of the API, wouldn't it be more efficient to
> change just those things than to start over from scratch?  Or worse,
> to have the Chrome filesystem API, the Firefox filesystem API, etc.?
> 
> If I understand correctly, folks at Mozilla think having a directory
> abstraction is too heavy-weight, and would prefer users to slice and
> dice paths by hand.  OK, that's a small change, and the
> functionality's roughly equivalent.  We could probably even make
> migration fairly easy with a small polyfill.
> 
> Jonas suggests FileHandle to replace FileWriter.  That's clearly not a
> move to greater simplicity, and no polyfill is possible, but it does
> open up the potential for higher perfomance, especially in a
> multi-process browser.  As i said when you proposed it, I'm
> interested, and we'd also like to solve the locking use cases.
> 
> Let's talk about it, rather than throw the baby out with the bathwater.
> 
> 	Eric
> 
> On Tue, Sep 18, 2012 at 4:04 AM, Olli Pettay <Olli.Pettay@helsinki.fi> wrote:
>> Hi all,
>> 
>> 
>> I think we should discuss about moving File API: Directories and System API
>> from Recommendation track to Note. Mainly because the API hasn't been widely
>> accepted nor
>> implemented and also because there are other proposals which handle the same
>> use cases.
>> The problem with keeping the API in recommendation track is that people
>> outside
>> standardization world think that the API is the one which all the browsers
>> will implement and
>> as of now that doesn't seem likely.
>> 
>> 
>> 
>> 
>> -Olli
>> 
>

Received on Saturday, 22 September 2012 00:37:54 UTC