- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 09 Nov 2009 16:21:06 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: Doug Schepers <schepers@w3.org>, "public-webapps@w3.org" <public-webapps@w3.org>, public-device-apis@w3.org
On Nov 9, 2009, at 12:08 PM, Ian Hickson wrote: > On Mon, 2 Nov 2009, Doug Schepers wrote: >> >> Please send in use cases, requirements, concerns, and concrete >> suggestions about the general topic (regardless of your opinion >> about my >> suggestion). > > Some use cases: > > * Ability to manage attachments in Web-based mail clients, both > receiving > and sending > * Ability to write a Web-based mail client that uses mbox files or the > Maildir format locally > * Ability to write a Web-based photo management application that > handles > the user's photos on the user's computer > * Ability to expose audio files to native media players > * Ability to write a Web-based media player that indexes the user's > media These are good use cases. > > Basically these require: > > - A per-origin filesystem (ideally exposed as a directory on the > user's > actual filesystem) > - The ability to grant read and/or write privileges to a particular > directory to an origin > - An API for files that supports reading and writing arbitrary ranges > - An API for directories that supports creating, renaming, moving, and > enumerating child directories and files Can you explain how these requirements follow from the use cases? It seems to me the use cases you cited would be adequately covered by: - Existing facilities including <input type="file"> with multiple selection. - File read facilities as outlined in the File API spec. - Ability to create named writable files in a per-origin private use area (with no specific requirement that they be browsable by the user, or in hierarchical directories). - Ability to write to a user-selected file (perhaps using something like <input type="save">). In particular I don't see how the second or fourth requirements follow from your use cases, and they seem to impose a great deal of security risk. I would not want to ship a Web-facing API that gives the ability to ask for read/write access to the user's full home directory. That seems like a security decision that the user does not have the information to make. Writing to files in a private use area, and one- time reading or writing files selected by the user (perhaps many at a time), seem much less risky. > I'd be happy to volunteer to edit the Directory component of this, > working > in tandem with Arun's draft for file access. I don't see how manipulation of directories is required for any of the use cases you cited. Regards, Maciej
Received on Tuesday, 10 November 2009 00:21:44 UTC