Re: Polished FileSystem API proposal

15 lip 2013 10:47, "Jonas Sicking" <jonas@sicking.cc> napisał(a):
>
> 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.
Yes, but if you change the offset to point to the beginnig of the file,
then a subsequent write happens there, unlike in posix, which would first
move the pointer to the eof and then write the data.
IMHO openAppend should be dropped. It will confuse people used to posix
style file access, and for others it's just a shorthand for
openWrite+location=null.

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