- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 3 Feb 2010 17:00:39 -0800
- 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