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 <[email protected]> wrote: > On Fri, Sep 21, 2012 at 5:37 PM, Maciej Stachowiak <[email protected]> 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
