Re: File API: Directories and System

On Apr 14, 2010, at 01:23 , Eric Uhrhane wrote:
>>  - 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.

So getCreationTime() has been suggested. I agree with you that it's a nice-to-have that can wait for v2 my only (slight) concern would be that we end up with a v2 that has duplicated functionality in the form of getModificationTime() and getMetadata(). But it's not a really strong concern.

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

Right, gotcha. I was aware of that discussion but failed to link the two. Then my comment is: please add the arguments :)

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

If we agree it's a nice-to-have, then I'd suggest we don't go down the path of creating a new URI scheme — that should only happen when it's completely unavoidable. Plus, it's a political quagmire.

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

Yup.

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

I'll see if I can add something, no promises on timeliness though.

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

There's a third option: One Locale To Rule Them All. We pick one and it's the one that everyone uses. It avoids two accesses to beißen/beissen working somewhere and biting somewhere else. Having been bitten by the likes of implementations that parsed numbers out of strings differently depending on locale, I can testify that it makes for really hard to find bugs.

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 14 April 2010 15:34:01 UTC