W3C home > Mailing lists > Public > public-device-apis@w3.org > April 2010

Re: File API: Directories and System

From: Robin Berjon <robin@robineko.com>
Date: Mon, 12 Apr 2010 14:19:34 +0200
Cc: public-device-apis@w3.org
Message-Id: <E677C760-568F-4ACC-96B3-26D66860B29E@robineko.com>
To: Eric Uhrhane <ericu@google.com>
Hi Eric,

On Apr 10, 2010, at 03:45 , Eric Uhrhane wrote:
> I've put up a draft of the filesystem API [1] based on the sketch I
> emailed out back in January [2].  It's a bit rough around the edges,
> but I wanted to get it up there for comments without making everyone
> wait any longer--no point in polishing it too much before it's set,
> anyway.

Thanks for the update! Just a few notes:

  - The Introduction could be a little bit fleshed out (but that's nothing urgent, naturally).
  - Section 3 jumps straight into telling us what constraints are imposed on permanent and temporary storage while we don't even know that both variants are possible yet. It might be that the paragraph that's right after the list of constraints should be right before it.
  - The first subsection of Section 3 has no title  is that intentional?
  - "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.
  - The paragraph on cookie-resurrection attacks sounds like it should be in the Security Considerations section.
  - Filesystem -> FileSystem in all those methods and interfaces?
  - "Some have requested support for archive files." I think that the two people interested in this were Arve and myself, and we're both happy to have that in a separate specification. I reckon that you can drop the issue. I like the idea that archives would return true for both isFile and isDirectory.
  - Entry.getModificationTime(): do we only want the modification time? Looking through the options for stat I don't see much else of value, but I'd rather ask early given that it's async. If we're going to want to query other similar aspects I'd rather have the all in one as getMetadata(); but if we feel we might stick to just the modification time then I'd rather not generalise thus.
  - It's a shame that Entry.getParent needs to be asynchronous, but I can't see a way around this. Suggestions welcome.
  - Entry.toURI() doesn't sound like it need to be a method, it could be Entry.uri (readonly).
  - There isn't a "bool" type in WebIDL, just "boolean". ReSpec should probably catch this.
  - "We should probably spec out at least the URI format" This can get scary, not to mention slow. Could this be URNs similar to those in File API (but without the expiration) or would you see it as something close to widget URIs but not just for widgets (http://dev.w3.org/2006/waf/widgets-uri/)?
  - DirectoryEntry.getDirectory() should be clear about what is meant by relative, whether that allows for "..", and what kind of error happens if the path doesn't match those constraints.
  - I'd rather we stayed away from bitwise options like CREATE|EXCLUSIVE and went for literal objects instead.
  - The explanation for EXCLUSIVE is a bit fuzzy if you haven't used an API with such an option before. It could be clarified a bit.
  - for EntrySync, I think that getParent() could be readonly attribute DirectoryEntrySync parent and getModificationTime could be readonly attribute Date modificationTime.
  - There's a lot of repeated text between the sync and async versions, I wonder if it would help you if ReSpec could include data from another section directly?
  - The first subsection of section 7 has no title. Right after it there is a </p> that is not preceded by a <p> (that is what causes the issue to eat over it afterwards).
  - "Case-insensitivity SHOULD respect the locale of the user." Really? Isn't there a risk that this will cause unpredictable effects when code runs on a locale it wasn't authored for?


Robin Berjon
  robineko  hired gun, higher standards
Received on Monday, 12 April 2010 12:20:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:19 UTC