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?