Re: New filesystem/directory API proposal

On Wed, Feb 3, 2010 at 4:54 PM, Ian Hickson <> wrote:
> On Wed, 3 Feb 2010, Eric Uhrhane wrote:
>> On Wed, Feb 3, 2010 at 3:55 PM, Ian Hickson <> 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.

That's about where we were when you came in ;'>.

Received on Thursday, 4 February 2010 01:01:29 UTC