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

Maciej Stachowiak wrote:
> On Sep 21, 2012, at 10:10 PM, Jonas Sicking<jonas@sicking.cc>  wrote:
>
>> 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.
>
> I took a crack at a pruned and cleaned up version:
>
> https://trac.webkit.org/wiki/MinimalFileStorage
>
> Only 4 interfaces (excluding the Navigator addition), 16 methods, 9 attributes. 
>

Nice!

> 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.

> It removes cruft but adds features relative to the Mozilla version:
>
> - Atomic create/open operation

As an old Unix hacker, this warms my heart. (I ignore the camelCaps 
method multiplication to avoid O_ flags, and the spelled-out creatE ;-)

> - Renaming files and directories

Atomic rename, must have.

> - A Directory interface for less weirdness in directory handling

+1

> - Ability to open files in append mode (this makes more sense than an append() operation on the handle, given the way underlying filesystems work) 
>

Yup.

> Features omitted include:
>   - Multiple named filesystems (just use directories)

Exactly. Do we still call them mount points?

> - Separate enumeration for writing (just use open)

Yup.

> - Ability to fetch matadata (does not appear to be needed for the use case) 
>

Whatsa mata with matadata? :-P

Ok, defer. Fine by me unless Sicking has a pressing use-case to articulate.

> It could be simplified a little bit, but really not that much, by removing hierarchy. 
>

Hierarchy is much of the point here.

I like the way this is going.

I'm curious how things look in hindsight to Google folks. Was the whole 
of FileSystem truly needed? Even if "whole" properly excludes the 
synchronous APIs?

/be

Received on Sunday, 23 September 2012 03:19:19 UTC