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

On Tue, 25 Sep 2012, Brendan Eich wrote:

> Maciej Stachowiak wrote:
>> On Sep 22, 2012, at 9:35 PM, Maciej Stachowiak<mjs@apple.com>  wrote:
>> 
>>> On Sep 22, 2012, at 8:18 PM, Brendan Eich<brendan@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.

Received on Tuesday, 25 September 2012 17:21:28 UTC