Re: New filesystem/directory API proposal

On Wed, 3 Feb 2010, Eric Uhrhane wrote:
> On Wed, Feb 3, 2010 at 3:55 PM, Ian Hickson <ian@hixie.ch> wrote:
> > On Wed, 3 Feb 2010, Eric Uhrhane wrote:
> >>
> >> I think that that's an important use case.  We want to make sure that 
> >> the browser isn't a silo whose data is awkward to access from 
> >> outside. If we can come up with a mapping that 1) works for all 
> >> possible filenames; 2) only shows up for the problem files; 3) 
> >> doesn't obfuscate external filenames too much, then I think we've got 
> >> a winner.  However, in the absence of such a solution, I think we 
> >> should stick with the least-common-denominator approach I've 
> >> outlined.
> >>
> >> If you've got a mapping in mind, I'm all ears.
> >
> > It's hard to determine a good mapping without knowing what the 
> > constraints are. What constraints did you have in mind?
> 
> See my first post in this thread for some basic restrictions; there will 
> likely be restrictions based on path and path-segment length.

For this you'd need several mappings: one from each filesystem to the API. 
Without knowing what the filesystem limitations are, exactly, it's hard to 
determine a good mapping.

If the API is the one that is constrained, though, rather than the 
filesystem, then maybe an even better solution is to just say that files 
that don't match the API simply aren't exposed. Or alternatively, maybe 
those files should be readable, but it should be impossible to _create_ a 
file with those names from the API.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'