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 16:09:40 -0800
Message-ID: <44b058fe1002031609s6762aa1aif79671ceee1bc457@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 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

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