- From: Kinuko Yasuda <kinuko@chromium.org>
- Date: Tue, 7 Sep 2010 00:41:46 -0700
- To: Eric Uhrhane <ericu@google.com>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>, abarth@webkit.org
- Message-ID: <AANLkTikNkvnM5mPNyvb=A59yaGExYbuz4gb6KKvM7dpg@mail.gmail.com>
Hi Eric, (re-sending from the correct address) I've been re-reading the spec and started wondering if we really want to have a new interface / javascript object for Flags. The Flags interface is used to specify two behavioral options (CREATE and EXCLUSIVE) for DirectoryEntry.getFile and getDirectory and defined as following: > > 4.2. The Flags Interface http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#the-flags-interface > > interface Metadata { > attribute boolean CREATE<http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#widl-Metadata-CREATE> ; > attribute boolean EXCLUSIVE<http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#widl-Metadata-EXCLUSIVE> ; > }; > (by the way I assumed you meant Flags but not Metadata.) > As the example code shows (4.2.2 Examples), each Flags object will likely be used as a 'one-time' object just to specify the behavior per each getFile/getDirectory. If that's the case, isn't it simpler/easier to use a bitfield and use single unsigned int parameter for the flags [proposal 1]? Or if we're not going to add more options it might be also good to simply use two separate boolean parameters [proposal 2]. > > [Proposal 1] > interface DirectoryEntry { > const unsigned short CREATE = 0x01; > const unsigned short EXCLUSIVE = 0x02; void getFile(in DOMString path, optional unsigned short options, ...); > > void getDirectory(in DOMString path, optional unsigned short options, ...); > ... > }; [Proposal 2] > interface DirectoryEntry { > void getFile(in DOMString path, bool create, bool exclusive, ...); > void getDirectory(in DOMString path, bool create, bool exclusive, ...); > ... > }; > What do you think? > Thanks, > Kinuko 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 Tuesday, 7 September 2010 07:42:37 UTC