- From: Robin Berjon <robin@robineko.com>
- Date: Mon, 7 Dec 2009 16:58:57 +0100
- To: <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com>
- Cc: <public-device-apis@w3.org>
Hi Richard, On Dec 4, 2009, at 12:58 , <richard.tibbett@orange-ftgroup.com> <richard.tibbett@orange-ftgroup.com> wrote: > In terms of extending that, and according to the programmatic example > provided of requesting to write a 'dahut.txt' file, what is the context > of dahut.txt? It is a *suggested* name for the file, which the user can then store anywhere. The reason it is only a suggestion is because UAs are encouraged to change the name in untrusted situations, if it doesn't seem to follow a sane pattern, or if its extension and its media type don't match (or yet again, if the media type is considered dangerous). The user is granted full liberty to save it wherever since the author knows nothing of the underlying FS. > As a user I would then be able to provide permission for this action > against either/both the sandbox and/or the file being requested: > > - allow write to this file (for the current site/session only) > AND/OR > - allow write to this sandbox (for the current site/session only) I don't think that at this level we yet have a safe way of writing arbitrary files to a user-level directory (especially not stuff like My Documents). Not from a browser I mean. The sequel spec for this one handles directory tree manipulation, including creating files. It also specifies localFS which is a sandboxed FS proper. And more importantly, it has the unsafe stuff that widgets may want to use in it. > Going further, some sandboxes may be implicitly writable such as the > site:// temp sandbox. If something's temp, it should be an implementation detail that authors don't see. For instance, you might create a Blob (which has an in-memory metaphor) but the UA, seeing it grow, may decide to make it a temp file. Once you have that behaviour, do you really need your own temp files? > I also think this could satisfy a number of use cases from e.g. BONDI. I think that the BONDI use cases will be addressed by the conjunction of this spec and the directory navigation one. The advantage of the split is that safe/browser systems can implement only the first one (or that plus safe parts of the other). -- Robin Berjon robineko — hired gun, higher standards http://robineko.com/
Received on Monday, 7 December 2009 15:59:33 UTC