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

What does getMetadata a synchronously return?

I think this API as written is still a fair bit more complex than needed for the sandboxed storage use case. It does seem simpler than Filesystem API.

Regards,
Maciej

On Sep 21, 2012, at 10:10 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> 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 21:39:46 UTC