On Wed, 09 Dec 2009 19:22:08 +0100, Robin Berjon <[email protected]>
wrote:
Note, I'm replying to both lists, but have set reply-to to
public-device-apis
as discussed in the joint WebApps API - DAP face to face, here is a
rough proposal for the Directories and System parts of the File API:
http://dev.w3.org/2009/dap/file-system/file-dir-sys.html
There are two entry points. One is through
navigator.device.fileSystems(), which upon success lists all available
FSs. Naturally that only expected to be exposed in trusted environments
(like widgets).
Some issues:
1. File and Directory are now mutually exclusive through the type
attribute of the "Entry" interface. This means that it's impossible to
have transparent handling of archive-type files. I would, given Widgets
and ODF, at least expect having the ability to support transparent
traversal in to .zip files from any specification, and thus rework the
proposal into entries of one type, with properties denoting one or the
other.
2. This specification should really be one about directory traversal, and
I would prefer to see any dependencies on FileReader or FileWriter
removed. This implies merging the relevant parts of Directory and
FileEntry into one type, namely "Entry".
3. When directory creation is concerned - having to recurse into the
directory you want, just in order to create a new file/directory handle is
somewhat inconvenient.
4. Dates associated with a file table entry are missing
5. Some (file system) properties of a file
(read/write/execute/archive/hidden) are missing
6. There seems to be no error handling when traversing in to directories
where the UA has no access.
7. I'm not sure I think the zip() method belongs in this spec at all: It
seems fairly arbitrary
8. If zip is to be kept, it needs to apply equally to any entry. It also
must be made async, as compression may take a long time.
9. The spec lacks any means to handle invalid file names. Note that doing
this is difficult, painful, and not at all consistent across file systems,
OSes and implementations. As an example, it's possible to create
filenames in Windows that Windows can't later delete.
10. The spec doesn't seem to concern itself with the character encoding of
the underlying file system. Intentional, or accident?
11. The spec also lacks a means of handling symbolic or hard links, or
junctions
12. The mediaType attribute when creating a new file is superfluous on
some systems, or may be in direct conflict with the file name.
13. The spec fails to address the file locking semantics on most operating
systems. Note that this problem should ideally be handled over to methods
from stream/blob interfaces.
Comments are very much welcome, *BUT* it is very much appreciated if
they can be made on the DAP's mailing list ([email protected])
rather than here.
Further replies directed to public-device-apis
--
Arve Bersvendsen
Opera Software ASA, http://www.opera.com/
