Re: File API: Directories and System

On Mon, Apr 12, 2010 at 5:19 AM, Robin Berjon <robin@robineko.com> wrote:
> 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:

Thanks for the feedback!

A lot of this is just first-draft roughness, and I'll take care of it
shortly and not respond to specifics here, but I've got some responses
below.

>  - 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.

Let's see if anyone suggests other metadata that needs adding.  If
it's just modification time, or even just that and one other, we might
just leave it as it is.  But if it looks like it's ever going to be at
least 3 items, I agree that it's worth making a generic accessor.

>  - 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).

Hmm...I think it will actually need to be a method, but I'd neglected
to add the parameters that would force that.  If you want to add a
content-disposition or mime-type header [say, to force the URL to
invoke the download handler], you'll need to add some way of supplying
that information.  There's been some discussion of this w.r.t. the
File API that's relevant:
http://lists.w3.org/Archives/Public/public-webapps/2010JanMar/0910.html.

>  - 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/)?

>From a quick glance, closer to the widgets spec, but really even
closer to a file:// URI.  I think it would be very useful if, given a
URI for a particular file, the user could generate URIs for nearby
files by herself.  If we used real paths, rooted in the domain's
sandbox, that'd be easy to do.  However, I don't see this as a hard
requirement, only a nice-to-have, and we could certainly get by with
opaque URNs [although it adds some bookkeeping for the implementor].

>  - 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.

You mean passing in something like { Create:true; Exclusive:true}?

>  - 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.

Given that it's a slow call to the filesystem, rather than a local
property, I think it's good to have getModificationTime as a method
invocation.  It gives a bit of a hint that it's not something you want
to do all the time.  On the other hand, getParent could probably be
cached, since that's not going to change very often.  I need to flesh
out the info on the risk of cached values going stale.  I don't want
to overspecify it, though, and make it restrictive of implementation.

>  - 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?

Probably.  I did a manual "See the error descriptions" thing, so
that's not duplicated, but it might help elsewhere.  Of course, in a
lot of places they two versions vary *just* enough to break a general
reference, but if I could use something fine-grained, possibly
per-parameter-description, that'd be nice.

>  - 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?

Well, I think we've got the choice of favoring the locale of the user
or the locale of the app developer.  We're going to break something
either way, and emulating the latter on a system whose underlying
platform isn't compatible could be pretty tricky.  I welcome
discussion on this from folks who've dealt with it before,
particularly folks who generally use less-common locales.

Received on Tuesday, 13 April 2010 23:24:01 UTC