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

On Fri, Sep 21, 2012 at 5:37 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
> 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.

For what it's worth, I put together a draft for what an API would look
like that has basically the same feature set as the current FileSystem
API, but based on DeviceStorage. It's a much smaller API that the
current FileSystem drafts, but supports things like shallow as well as
deep directory iteration.

https://wiki.mozilla.org/WebAPI/DeviceStorageAPI2

I think that if we at mozilla were to implement a sandboxed
filesystem, it'd be something more like this.

The FileHandle part of the API is definitely more complex to implement
than the FileWriter API, but I'd argue that it's actually easier to
use. For example you can start multiple write operations without
having to wait for each individual write to finish.

I also added an example of what a read-only DeviceStorage would look
like if we wanted something like that for <input type=file>,
drag'n'drop or a zip-reader. This shouldn't be considered as part of
the remaining draft though since exposing a filesystem in those
scenarios might very well be overkill.

/ Jonas

Received on Saturday, 22 September 2012 05:11:16 UTC