Re: New draft of FileSystem API posted

Fixed.

While I was in there, I deleted an unused class [FileSystemsCallback]
and changed the boolean "persistent" parameter [from requestFileSystem
and requestFileSystemSync] to be a more-general flag, to allow for
future expansion.

   Eric

On Fri, Aug 13, 2010 at 11:23 AM, Kinuko Yasuda <kinuko@chromium.org> wrote:
> On Fri, Aug 13, 2010 at 10:58 AM, Eric Uhrhane <ericu@google.com> wrote:
>>
>> On Thu, Aug 12, 2010 at 11:08 PM, Kinuko Yasuda <kinuko@chromium.org>
>> wrote:
>> > 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?
>>
>> You're quite right.  A mutable FileEntry shouldn't have a synchronous
>> size member, and slice() and type are likewise problematic.
>>
>> How about if we add a getFile() method that returns a File object,
>> snapshotted at the time of the call?  Hmm...that name's going to be a
>> bit confusing, though, since there's a getFile on DirectoryEntry that
>> does something completely different.  Perhaps just file()?  It should
>> definitely be a method, not a member, to make clear that it's making
>> calls to the underlying filesystem.
>
> file() sounds good to me.
> (Oh yes we have getFile on DirectoryEntry...)
>
>>
>> > 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
>> >> >>
>> >> >
>> >> >
>> >
>> >
>
>

Received on Saturday, 14 August 2010 00:07:28 UTC