W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2014

RE: FileSystem API Comments

From: Jonathan Bond-Caron <jbondc@gdesolutions.com>
Date: Wed, 22 Oct 2014 10:23:40 +0000
To: Jonas Sicking <jonas@sicking.cc>, Ali Alabbas <alia@microsoft.com>
CC: WebApps WG <public-webapps@w3.org>
Message-ID: <9a2591b420bf4ede9b004854a729ddf1@BN1PR07MB135.namprd07.prod.outlook.com>
On Tue Oct 21 09:36 PM, Jonas Sicking wrote:
> > 1.1 Use cases (3. Audio/Photo editor with offline access or local
> > cache for
> > speed)
> >
> >   * Edited files should be accessible by other client-side
> > applications
> >
> >      - Having the sandboxed file system share its contents between all
> > apps would allow apps to tamper with the files of another app. This
> > could result in corrupted files and perhaps an invalid state for some
> > apps that expect certain contents to exist in a file. This makes us
> > wonder: should we warn users about files that are being opened and
> > written to? 
> 
> Each origin has a separate sandboxed filesystem. There is no way for websites
> to read each other's filesystems. This is no different from IndexedDB or
> localStorage. This also means that we have the same prompting behavior, the
> same Quota Management dependency and the same security model as
> IndexedDB and localStorage.
> 

That contradicts:
- Edited files should be accessible by other client-side applications

The api should allow for editing a 'shared folder' which multiple applications / web apps can access.
That implies a sort of locking/unlocking api:

e.g.
photo editor
fs = api.getFileSystem({shareName: "photos"}).then((dir) => { dir.openWrite("pic.jpeg") });

super photo viewer
fs = api.getFileSystem({shareName: "photos"}).then((dir) => { dir.openRead("pic.jpeg") });

What happens with the pic.jpeg?
Received on Wednesday, 22 October 2014 10:24:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:31 UTC