- From: Arve Bersvendsen <arveb@opera.com>
- Date: Thu, 10 Dec 2009 14:11:59 +0100
- To: "Robin Berjon" <robin@robineko.com>, "public-webapps WG" <public-webapps@w3.org>, public-device-apis <public-device-apis@w3.org>
On Wed, 09 Dec 2009 19:22:08 +0100, Robin Berjon <robin@robineko.com> 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 (public-device-apis@w3.org) > rather than here. Further replies directed to public-device-apis -- Arve Bersvendsen Opera Software ASA, http://www.opera.com/
Received on Thursday, 10 December 2009 13:12:38 UTC