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

Re: New filesystem/directory API proposal

From: Eric Uhrhane <ericu@google.com>
Date: Wed, 3 Feb 2010 17:00:39 -0800
Message-ID: <44b058fe1002031700h14db9dd0qb5eedba23ba4df4@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Michael Nordman <michaeln@google.com>, public-device-apis@w3.org
On Wed, Feb 3, 2010 at 4:54 PM, Ian Hickson <ian@hixie.ch> wrote:
> 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.

That's about where we were when you came in ;'>.
Received on Thursday, 4 February 2010 01:01:29 UTC

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