- 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>
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