On Tue, 25 Sep 2012, Brendan Eich wrote:

Maciej Stachowiak wrote:
On Sep 22, 2012, at 9:35 PM, Maciej Stachowiak<m...@apple.com>  wrote:

On Sep 22, 2012, at 8:18 PM, Brendan Eich<bren...@mozilla.com>  wrote:

And two of the interfaces are generic and reusable in other contexts.
Nice, and DOMRequest predates yours -- should it be done separately since (I believe) it is being used by other proposals unrelated to FileSystem-like ones?

Sorry if I missed it and it's already being split out.
Yes, I borrowed DOMRequest. I think DOMRequest and DOMMultiRequest could be a separate spec, if that sort of asynchronous response pattern is generally useful. And it seems like it might be. That would leave only two interfaces specific to the Minimal File System proposal, Directory and FileHandle.

Here's an alternate version where I renamed some things to match Filesystem API and FileWriter, and added the missing key feature of getting a persistent URL for a file in a local filesystem (extending the URL interface). It's still a much simpler API that provides most of the same functionality.

https://trac.webkit.org/wiki/MinimalFileStorageAlternate

Even better.

What's the next step? I would hope we can make device storage be this, but that's just old Unix-hacker me (yes, no pathnames, you have to namei by calling get for each component -- that's a feature).

*Personally* I like this proposal more than the original Google one, but I'm still have concerns. Every operation requiring a callback seems likely to lead to a "pyramid of doom" and unmaintainable code. Since this seems to be an increasing problem with certain classes of JS APIs (the SQL API had similar issues and I wouldn't be surprised if IndexedDB has too), it seems like we should work out some solution, either at the langauge level or at the DOM level, for managing this complexity rather than adding new features that require it. Obviously workers and a sync API are one option, but having to keep a worker around just to do storage operations also seems rather burdensome.

In addition, this would be the fourth storage API that we have tried to introduce to the platform in 5 years (localStorage, WebSQL, IndexedDB being the other three), and the fifth in total. Of the four APIs excluding this one, one has failed over interoperability concerns (WebSQL), one has significant performance issues and is discouraged from production use (localStorage) and one suffers from a significant problems due to its legacy design (cookies). The remaining API (IndexedDB) has not yet achieved widespread use. It seems to me that we don't have a great track record in this area, and rushing to add yet another API probably isn't wise. I would rather see JS-level implementations of a filesystem-like API on top of IndexedDB in order to work out the kinks without creating a legacy that has to be maintained for back-compat than native implementations at this time.

Reply via email to