On Nov 11, 2009, at 3:51 PM, Eric Uhrhane wrote:
On Mon, Nov 9, 2009 at 4:21 PM, Maciej Stachowiak <m...@apple.com>
wrote:
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).
I think that exposing audio files to native players would require the
ability to create directories in the native filesystem, thus making
them browsable. Sure, you could just toss them in a single directory
without hierarchy, but that's not a great user experience, and it hits
serious performance problems with large audio collections. The same
problems would affect the photo manager.
With the native music player I'm most familiar with, iTunes, the user
is not even really aware of where audio files are in the file system.
It does use a directory hierarchy, but it's pretty rare for users to
actually poke around in there. And the iPod application on iPhone (as
well as the iPod itself) do not even have a user-visible filesystem
hierarchy. So overall I don't buy hierarchical directories as a hard
requirement to build a music player or to expose content to a music
player.
That being said, I think creating subdirectories in a per-origin
private use area is probably less risky than user-granted privilege to
manipulate directories elsewhere in the filesystem. But I would be
inclined to avoid this mechanism at first, and if it is needed, start
with the bare minimum. I'm not convinced by your argument that it is
necessary.
- 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.
As stated above, the fourth requirement is needed for audio and
photos. The second requirement is needed for the photo manager if
it's going to be allowed to manage photos that it didn't download
itself. How else can it access "My Photos" or wherever I dragged the
photos off my camera?
The common way this would happen between two native apps would be to
have an import process of the photo files.
However, I agree that the second requirement in particular poses large
security risks. In this email to public-webapps [1] (but not CCed to
DAP--sorry about that) I split up a list of use cases into two groups
based on requirements. I think we'll make a lot more progress if we
talk about the less-scary group first, which specifically avoids
requirement 2.
That sounds sensible to me as well.
I'm not sure that any of my use cases in group 1 really require a
directory API, but they'll perform better and be nicer to use with
one.
Are there usability studies showing any of the apps you mention are
more usable if they store data in hierarchical directories? I would be
surprised, because users are increasingly managing large file
collections with "shoebox" apps that reflect an organization
completely separate from the filesystem hierarchy. Do you have any
performance test results to back up the performance claim?
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.
-Eric
[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html
