W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: Flags for getFile/getDirectory (Re: New draft of FileSystem API posted)

From: Kinuko Yasuda <kinuko@chromium.org>
Date: Tue, 7 Sep 2010 00:41:46 -0700
Message-ID: <AANLkTikNkvnM5mPNyvb=A59yaGExYbuz4gb6KKvM7dpg@mail.gmail.com>
To: Eric Uhrhane <ericu@google.com>
Cc: Web Applications Working Group WG <public-webapps@w3.org>, abarth@webkit.org
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT