- From: Eric Uhrhane <ericu@google.com>
- Date: Wed, 3 Feb 2010 16:09:40 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: Michael Nordman <michaeln@google.com>, public-device-apis@w3.org
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. If you mean what are the design constraints, the idea is that you can write a web app that runs the same on any browser on any platform, without regard to the underlying filesystem, and can easily share files with client apps on that platform. App developers should have reasonable freedom in the choice of naming their client-side files; often users or legacy client-side apps will pick the names. In order to make this reasonably easy to implement on the vast majority of systems, I enumerated restrictions that can be satisfied or emulated easily on reasonably modern Windows, Mac, Linux, BSD, and other Unixy systems.
Received on Thursday, 4 February 2010 00:10:28 UTC