Re: Polished FileSystem API proposal

On Mon, Jul 15, 2013 at 12:18 AM, Janusz Majnert <j.majnert@samsung.com> wrote:
> 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?

That seems better yeah.

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

No. It's just initially set to the end of the file. Though since every
write moves the offset to the end of the write, that means that the
offset will remain at the end of the file unless explicitly set.

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

It is indeed.

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

I can think of four reasons, though none of them particularly great.

* While it's not a primary target for this API, it's nice if we can
reuse the same API if we ever end up introducing APIs that will allow
accessing real filesystems. Though you could argue that it's ok if you
in that case too always open the file in readwrite mode.
* Even in a sandboxed filesystem you could end up with multiple actors
accessing the filesystem at the same time. For example the user might
have the same website open in two tabs. Or you might have a worker and
a page accessing the file at the same time. With openRead you can
allow multiple simultaneous readers.
* We might want to support a read-only filesystem in some situations.
For example if the user uses drag'n'drop to expose a folder to a page,
we could expose that folder using a read-only version of the Directory
interface. Though in that case not exposing open* at all and instead
relying on get() would probably work.
* A main reason we're considering exposing a filesystem API at all is
it's a familiar concept to authors. And most filesystem APIs have
openRead and openWrite (and posix has openAppend).

/ Jonas

Received on Monday, 15 July 2013 08:45:46 UTC