- From: Petka Antonov <notifications@github.com>
- Date: Thu, 05 Nov 2015 02:27:46 -0800
- To: w3c/FileAPI <FileAPI@noreply.github.com>
- Message-ID: <w3c/FileAPI/issues/27@github.com>
Currently blob urls don't persist between browser restarts / page refreshes etc so the user has to add same files to the app over and over again everytime the app is started. For certain kinds of apps it is necessary to be able to create a persistent blob url. For instance a media player app that has access to the media files the user has added to the app so they don't have to keep readding the files (possibly thousands) every time the app is started. Duplicating copies of the files in FileSystem or IndexedDB is out of the question as this duplicates possibly gigabytes of data which takes a long time, wastes a lot of storage and hits limits quickly. **Reading** I suggest a method like `URL.createPersistentObjectUrl` is added. The url is valid as long as the original file exists in exactly same location with exactly same attributes and contents as they were when the URL was created. When the file is modified, moved or altered in any way, the url should become invalid (perhaps `URL.isPersistentUrlValid` can be used to check it?). This can be probably done just by checking the last modified attribute. **Writing** One could also be allowed to write to a valid persistent object urls by sending binary data as a POST request to the url. However, *every* time such a POST request is made, the browser should prompt the user for confirmation that "the app wants to modify the flie at [path], is this ok?". Also such requests should probably only be allowed to made in response to user event like click. After successful write, the browser should update the persistent object url to match the new file attributes and contents that were updated. Security considerations As far as I can see, this should not give the app access to any more information than existing APIs already give. --- Reply to this email directly or view it on GitHub: https://github.com/w3c/FileAPI/issues/27
Received on Thursday, 5 November 2015 10:28:15 UTC