Re: Polished FileSystem API proposal

Hi,

On 2013-07-13 02:31, Jonas Sicking wrote:
> [...]
> interface FileHandle
> {
>    readonly attribute FileOpenMode mode;
>    readonly attribute boolean active;
>
>    attribute long long? location;
"location" seems to be a bad name. It might be confused with "location 
in the filesystem". Why not use "offset" instead? Is this value 0-based?

>
>    Promise<File> getFile();
>    AbortableProgressPromise<ArrayBuffer> read(unsigned long long size);
>    AbortableProgressPromise<DOMString> readText(unsigned long long
> size, optional DOMString encoding = "utf-8");
>
>    void abort();
> };
>
> interface FileHandleWritable : FileHandle
> {
>    AbortableProgressPromise<void> write((DOMString or ArrayBuffer or
> ArrayBufferView or Blob) value);
>
>    Promise<void> setSize(optional unsigned long long size);
>
>    Promise<void> flush();
> };
>
> partial interface URL {
>    static DOMString? getPersistentURL(File file);
> }
>
> // WebIDL cruft that's largely transparent
> enum PersistenceType { "temporary", "persistent" };
> dictionary FilesystemParameters {
>    PersistenceType storage = "temporary";
> };
>
> dictionary MakeFileOptions {
>    boolean overwriteIfExists = false;
>    (DOMString or Blob or ArrayBuffer or ArrayBufferView) data;
> };
>
> enum CreateMode { "createifneeded", "dontcreate" }
> enum DeleteMode { "recursive", "nonrecursive" }
>
> dictionary DestinationDict {
>    Directory dir;
>    DOMString name;
> };
>
> enum FileOpenMode { "read", "write", "append" };
>
 > [...]
 >
> Do we really need the .openAppend() function? Or is it ok to ask
> people to use .openWrite() and then go to the end before writing?

In the "append" mode, is the "location" in file changed to the end of 
file before every write? If not, then I think openAppend should be 
removed. In the example you gave at the bottom of your message, it seems 
that it's actually possible to write in the middle of the file.

Another non-posix thing is that you can read a file that is in "write" mode.
I would therefore propose to:
* remove openAppend()
* change enum FileOpenMode to {"read", "readWrite"}

In another email you wrote that this API is not meant to be used to 
access the OS filesystem, but a "snadboxed" filesystem abstraction for a 
webapp. If so, why do we even need the two access modes? Let's just have 
an openFile() that returns a File object you can read and write to.



-- 
Janusz Majnert
Samsung R&D Institute Poland
Samsung Electronics

Received on Monday, 15 July 2013 07:18:58 UTC