- From: Eric Uhrhane <ericu@google.com>
- Date: Fri, 13 Aug 2010 17:06:42 -0700
- To: Kinuko Yasuda <kinuko@chromium.org>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
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