Re: New draft of FileSystem API posted

Hi Eric,

Thanks for your reply.
Actually after sending that email I had started to think that caching isFile
/ isDirectory information in memory would be ok if user could get an
informative error code when an entry becomes stale -- and seems like that's
the case.  So I'm almost convinced :)

One thing I'm not fully convinced yet about FileEntry / DirectoryEntry is
if we really want to make FileEntry a subclass of File.

To me it looks like they have slightly different semantics - File is an
immutable snapshot of file content, while Entry is more like a handle for
meta-level operations that actually modify the underlying disk image.

File's size attribute and slice() method assume its snapshot doesn't change
after it was captured, but FileEntry has createWriter method and it will
likely change the file content.  It brings several questions: if FileEntry
== File in what timing are UAs supposed to capture a snapshot?  Do we want
to have a synchronous size attribute on a mutable Entry?  If we move an
Entry to another name, does its File.type need to change according to its
new name?


On Wed, Aug 11, 2010 at 1:25 PM, Eric Uhrhane <ericu@google.com> wrote:

> My apologies for the slow response; I'm now back from my vacation.
>
> On Tue, Jul 20, 2010 at 6:27 PM, Kinuko Yasuda <kinuko@google.com> wrote:
> > Hi Eric,
> > Thanks for brushing up the draft.
> > We had some internal discussion about the API details and came up with a
> > question regarding is{File,Directory} attributes of Entry interface.
> > It seems like user agent needs to be able to tell if a given entry is
> file
> > or directory synchronously (or from its cache), but we wonder what should
> > happen if the underlying file object is changed later.  For example, we
> may
> > have a situation like this:
> > 1. a user code gets (or creates) a file entry.
> > 2. another flow of the code (or another code in the same origin) removes
> the
> > same entry and creates a *directory* at the same path.
> > 3. the original code refers isFile attribute of the entry. -- should it
> be
> > true or false?
>
> My intention was that the UA would look up that information when first
> creating the Entry and keep it cached.  It's not the kind of thing
> that changes very often, so I didn't think we needed it to be a live
> query every time.  If the user tries to write to a file that's become
> a directory, or vice-versa, that's what INVALID_STATE_ERROR is for.

This is an unusual error, thus it's appropriate that it be handled via
> exception.


> If an Entry is just a reference (i.e. a pathname) of a system file entity,
> > it would look natural that it is resolved at run-time thus returns false
> in
> > the above case.   But if so we'll have two problems: 1) we'll need to
> make
> > synchronous stat calls to get the attribute values, and 2) as we have
> > different interfaces for file and directory, we may end up with having
> > invalid FileEntry objects for directories - or vice versa.
> > Would it be possible to have a single unified interface for file and
> > directory and let scripts figure out the info at runtime (e.g. in each
> > asynchronous filesystem operation)?
>
> Do you mean, allow all file operations and directory operation, and
> fail if you use the wrong one?  UAs already have to fail on operations
> that don't make sense [or fail in the underlying implementation],
> whether or not we keep a unified interface, so I think that would just
> clutter up each subtype with the others' methods.
>


> If I'm misunderstanding you, please give an example of your proposed
> interface and a situation which it would improve.


You're not misunderstanding me.   I meant if UAs didn't cache the
information that an entry is file or directory it would be natural to make
wrong operations fail at run-time, but otherwise I fully agree that
cluttering up subtypes with irrelevant methods is not a good idea.

> On Wed, Jul 7, 2010 at 6:50 PM, Eric Uhrhane <ericu@google.com> wrote:
> >>
> >> I've posted a new draft of File API: Directories and System [1].  In
> >> this draft I've rolled in quite a bit of feedback that I received
> >> since first posting it on DAP--many apologies for the delay.  This is
> >> the first draft produced since we agreed to move this spec from DAP to
> >> WebApps; I hope those of you who have time will give it a look and let
> >> me know what you think.
> >>
> >> In general I've tried to address any comment I was sent and had not
> >> already addressed via email.  The few that didn't make it in, I've
> >> responded to below.
> >>
> >> My thanks to Robin Berjon and Mike Clement for all their feedback.
> >>
> >> Robin:
> >>  - "data stored there by the application should not be deleted by the
> >> UA without user intervention", "UA should require permission from the
> >> user", "The application may of course delete it at will" -> these
> >> sound like real conformance statements, therefore SHOULD, SHOULD NOT,
> >> and MAY.
> >>
> >> Those are in a non-normative section; is that language still appropriate
> >> there?
> >>
> >> Robin:
> >> [discussion about speccing the URI format]
> >>
> >> Left as an open issue.
> >>
> >> Mike:
> >> [discussion about multiple sandboxes per origin]
> >>
> >> I think that would be very easy and clean to add later if desired, and
> >> in the mean time, one can use subdirectories.
> >>
> >> Mike:
> >> getFile/getDirectory are a bit overloaded.  How about including
> >> methods like exists(), createFile() and createDirectory()?  Though
> >> these methods are easily implemented in terms of getFile/getDirectory,
> >> I always prefer more direct API methods that help make the code easier
> >> to understand.  I expect, though, that you are attempting to be a low
> >> level as possible here.
> >>
> >> As Robin pointed out, adding extra round-trips will slow things down.
> >> Also, it can encourage race conditions.  These are easy for libraries
> >> to implement via wrappers.
> >>
> >> Mike:
> >> [request for creation time in getMetadata]
> >>
> >> It may be hard to support reliably cross-platform [2].
> >>
> >> Robin:
> >> [specifying a single locale everywhere]
> >>
> >> I don't think that'll make folks very happy if it's not their locale.
> >> If I e.g. try to force my locale on Turkish Windows users, they're
> >> going to see some interesting errors trying to share files with apps
> >> outside the browser, or for that matter even saving certain groups of
> >> files from inside the browser.
> >>
> >>    Eric
> >>
> >> [1] http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
> >> [2] http://en.wikipedia.org/wiki/MAC_times
> >>
> >
> >
>