- From: Eric Uhrhane via cvs-syncmail <cvsmail@w3.org>
- Date: Thu, 08 Jul 2010 01:25:41 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/file-system
In directory hutz:/tmp/cvs-serv10414
Modified Files:
file-dir-sys.html
Log Message:
Fix some relative/absolute path stuff.
Index: file-dir-sys.html
===================================================================
RCS file: /sources/public/2009/dap/file-system/file-dir-sys.html,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -d -r1.9 -r1.10
--- file-dir-sys.html 8 Jul 2010 00:52:17 -0000 1.9
+++ file-dir-sys.html 8 Jul 2010 01:25:38 -0000 1.10
@@ -163,27 +163,27 @@
<section class='informative'>
<h2>Temporary vs. Persistent Storage</h2>
<p>
- An application can request temporary or persistent storage space.
- Temporary storage may be easier to get, at the UA's discretion [looser
- quota restrictions, available without prompting the user], but the
- data stored there may be deleted at the UA's convenience, e.g. to deal
- with a shortage of disk space.
+ An application can request <a>temporary</a> or <a>persistent</a>
+ storage space. Temporary storage may be easier to get, at the UA's
+ discretion [looser quota restrictions, available without prompting the
+ user], but the data stored there may be deleted at the UA's
+ convenience, e.g. to deal with a shortage of disk space.
</p>
<p>
- Conversely, once persistent storage has been granted, data stored
- there by the application should not be deleted by the UA without user
- intervention. The application may of course delete it at will. The
- UA should require permission from the user before granting persistent
- storage space to the application.
+ Conversely, once <a>persistent</a> storage has been granted, data
+ stored there by the application should not be deleted by the UA
+ without user intervention. The application may of course delete it at
+ will. The UA should require permission from the user before granting
+ <a>persistent</a> storage space to the application.
</p>
<p>
This API specifies the standard origin isolation in a filesystem
context, along with persistence of data across invocations.
- Applications will likely use temporary storage for caching, and if
- it's still around from a previous session, it is often useful.
+ Applications will likely use <a>temporary</a> storage for caching, and
+ if it's still around from a previous session, it is often useful.
Persistent data, on the other hand, is useless if you can't access it
- again the next time you're invoked. However, even with persistent
- data, the user may delete it manually [either through the UA or via
+ again the next time you're invoked. However, even <a>persistent</a>
+ data may be deleted manually by the user [either through the UA or via
direct filesystem operations].
</p>
</section>
@@ -194,9 +194,15 @@
<ul>
<li>The filesystems accessible by any origin MUST be disjoint from
those accessible by any other origin.</li>
+ <li>Data stored in a <dfn>persistent</dfn> filesystem SHOULD NOT be
+ deleted by the UA, other than in response to a removal API call,
+ without explicit authorization from the user.</li>
+ <li>Data stored in a <dfn>temporary</dfn> filesystem MAY be deleted by
+ the UA at its discretion, without application or user
+ intervention.</li>
<li>If
<ol>
- <li> an application in a given origin requests a persistent
+ <li> an application in a given origin requests a <a>persistent</a>
filesystem on multiple occasions;</li>
<li> each request is granted;</li>
<li> and data from an earlier request still exists in the first
@@ -207,7 +213,7 @@
and root directory as the previous request.</li>
<li>If
<ol>
- <li> an application in a given origin requests a temporary
+ <li> an application in a given origin requests a <a>temporary</a>
filesystem on multiple occasions;</li>
<li> each request is granted;</li>
<li> and data from an earlier request still exists in the first
@@ -216,11 +222,13 @@
then the <a>FileSystem</a> or <a>FileSystemSync</a> returned from
the subsequent request SHOULD refer to the same underlying
filesystem and root directory as the previous request.</li>
- <li>Data stored in a temporary filesystem MAY be deleted by the UA at
- its discretion, without application or user intervention.</li>
- <li>Data stored in a persistent filesystem SHOULD NOT be deleted by
- the UA, other than in response to a removal API call, without explicit
- authorization from the user.</li> </ul>
+ <ul>
+ <div class='issue'>
+ <p>
+ Do we need to mandate that the <a>temporary</a> and
+ <a>persistent</a> filesystems be disjoint?
+ </p>
+ </div>
</section>
<section class='informative'>
<h2>Security Considerations</h2>
@@ -257,7 +265,7 @@
cookie-resurrection attacks. UAs will likely wish to present the
option of clearing it when the user clears any other origin-specific
storage, blocking access to it when cookies are blocked, etc. This is
- especially important if temporary storage space is permitted by
+ especially important if <a>temporary</a> storage space is permitted by
default without explicit user permission.
</p>
</section>
@@ -289,8 +297,8 @@
<dl class='parameters'>
<dt>boolean persistent</dt>
<dd>
- Whether the filesystem requested should be persistent, as
- defined above.
+ Whether the filesystem requested should be <a>persistent</a>,
+ as defined above.
</dd>
<dt>long long size</dt>
<dd>
@@ -353,8 +361,8 @@
<dl class='parameters'>
<dt>boolean persistent</dt>
<dd>
- Whether the filesystem requested should be persistent, as
- defined above.
+ Whether the filesystem requested should be <a>persistent</a>,
+ as defined above.
</dd>
<dt>long long size</dt>
<dd>
@@ -509,9 +517,7 @@
</dd>
<dt>readonly attribute DOMString fullPath</dt>
<dd>
- The full path from the root to the entry. Paths are always
- <code>/</code> separated irrespective of the convention used by the
- underlying file system.
+ The full <a>absolute path</a> from the root to the entry.
</dd>
<dt>readonly attribute FileSystem filesystem</dt>
<dd>
@@ -655,9 +661,10 @@
<dl class='parameters'>
<dt>DOMString path</dt>
<dd>
- The <a>relative path</a> from this DirectoryEntry to the
- file to be looked up or created. It is an error to attempt
- to create a file whose immediate parent does not yet exist.
+ Either an <a>absolute path</a> or a <a>relative path</a> from
+ this DirectoryEntry to the file to be looked up or created. It
+ is an error to attempt to create a file whose immediate parent
+ does not yet exist.
</dd>
<dt>optional Flags options</dt>
<dd>
@@ -694,9 +701,10 @@
<dl class='parameters'>
<dt>DOMString path</dt>
<dd>
- The <a>relative path</a> from this DirectoryEntry to the
- directory to be looked up or created. It is an error to attempt
- to create a directory whose immediate parent does not yet exist.
+ Either an <a>absolute path</a> or a <a>relative path</a> from
+ this DirectoryEntry to the directory to be looked up or created.
+ It is an error to attempt to create a directory whose immediate
+ parent does not yet exist.
</dd>
<dt>optional Flags options</dt>
<dd>
@@ -987,9 +995,7 @@
</dd>
<dt>readonly attribute DOMString fullPath</dt>
<dd>
- The full path from the root to the entry. Paths are always
- <code>/</code> separated irrespective of the convention used by the
- underlying file system.
+ The full <a>absolute path</a> from the root to the entry.
</dd>
<dt>readonly attribute FileSystemSync filesystem</dt>
<dd>
@@ -1154,9 +1160,10 @@
<dl class='parameters'>
<dt>DOMString path</dt>
<dd>
- The <a>relative path</a> from this DirectoryEntrySync to the
- file to be looked up or created. It is an error to attempt
- to create a directory whose immediate parent does not yet exist.
+ Either an <a>absolute path</a> or a <a>relative path</a> from
+ this DirectoryEntrySync to the file to be looked up or created.
+ It is an error to attempt to create a file whose immediate
+ parent does not yet exist.
</dd>
<dt>optional unsigned short options</dt>
<dd>
@@ -1202,9 +1209,10 @@
<dl class='parameters'>
<dt>DOMString path</dt>
<dd>
- The <a>relative path</a> from this DirectoryEntrySync to the
- directory to be looked up or created. It is an error to attempt
- to create a directory whose immediate parent does not yet exist.
+ Either an <a>absolute path</a> or a <a>relative path</a> from
+ this DirectoryEntrySync to the directory to be looked up or
+ created. It is an error to attempt to create a directory whose
+ immediate parent does not yet exist.
</dd>
<dt>optional unsigned short options</dt>
<dd>
@@ -1529,19 +1537,26 @@
<section>
<h2>Directories</h2>
<p>
- A <dfn>relative path</dfn> describes how to get from a particular
- directory to a file or directory. All paths presented to this API are
- relative paths. All methods that accept paths are on
- <a>DirectoryEntry</a> or <a>DirectoryEntrySync</a> objects; the paths
- are interpreted as being relative to the directories represented by
- these objects.
+ The directory separator is '/', regardless of the directory separator
+ used by the underlying system, if any.
</p>
<p>
- As all paths are relative, paths MUST NOT start with '/'.
+ The character '/', when it is the first character in a path, refers to
+ the root directory.
</p>
<p>
- The directory separator is '/', regardless of the directory separator
- used by the underlying system, if any.
+ All absolute paths begin with '/'; no relative paths begin with '/'.
+ </p>
+ <p>
+ A <dfn>relative path</dfn> describes how to get from a particular
+ directory to a file or directory. All methods that accept paths are on
+ <a>DirectoryEntry</a> or <a>DirectoryEntrySync</a> objects; the paths,
+ if relative, are interpreted as being relative to the directories
+ represented by these objects.
+ </p>
+ <p>
+ An <dfn>absolute path</dfn> is a <a>relative path</a> from the root
+ directory, prepended with a '/'.
</p>
<p>
'.', when used where it is legal to use a directory name, refers to the
Received on Thursday, 8 July 2010 01:25:46 UTC