RE: Request for feedback: Filesystem API

> However, I think one major issue with the interface is that it is about as far as a proposal possibly could be from embracing the extensible web principles that we've recently been pushing [1]. A filesystem API seems like the *perfect* candidate for applying the "add new low-level capabilities, allow web developers to iterate on higher-level ones, then standardize later" approach.
>
> For example:
>
> - At a glance, move, copy, removeDeep, and enumerateDeep seem like derivative APIs.

On one hand, there is enumerateDeep. This function seem quite straightforward. I wouldn't mind it to be included in some way.

On the other hand, the other functions suffer from huge design challenges (what to do in case of conflict? are hidden files copied too? what happens if only one file is corrupted?) and I would probably leave then out, too. Librairies can fill the gap and we can learn from experiments before standardising.





> - The readText method of the FileHandle, which has design problems in terms of not taking into account the stateful nature of encoding-specific text reading anyway, is probably best built by providing a lower-level primitive like a string-decoder duplex stream or transform, instead of baking that into the file handle stream itself. Of course one of the benefits of this would be that such string decoding capabilities would be usable by other parts of the platform as well! #extendthewebforward

+1




> - The AbortableProgressPromise idea is way overkill. As Isaac so clearly outlined, it makes no sense for streaming APIs generally. That leaves it for use in move and copy, both of which are derivative operations. As such I think user-space implementations will be in a better position to compose the file stream operations into a cancellable and/or progress-emitting implementation of move and copy. That way we can have an API that users actually like, instead of having the AbortableProgressPromise idea---which the promise community is generally negative toward---be shoved at us by the W3C.

+1

Received on Saturday, 10 August 2013 03:27:26 UTC