Re: File API: Directories and System

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