- From: Eric Uhrhane via cvs-syncmail <cvsmail@w3.org>
- Date: Wed, 16 Mar 2011 23:33:51 +0000
- To: public-dap-commits@w3.org
Update of /sources/public/2009/dap/file-system
In directory hutz:/tmp/cvs-serv23056
Modified Files:
file-dir-sys.html
Log Message:
Change resolveFileSystemURI->resolveFileSystemURL and toURI->toURL.
Index: file-dir-sys.html
===================================================================
RCS file: /sources/public/2009/dap/file-system/file-dir-sys.html,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -d -r1.29 -r1.30
--- file-dir-sys.html 11 Feb 2011 00:55:01 -0000 1.29
+++ file-dir-sys.html 16 Mar 2011 23:33:49 -0000 1.30
@@ -79,7 +79,7 @@
the background, so going to the next game level or activating a new
feature doesn't require waiting for a download.</li>
<li>It uses those assets directly from its local cache, by direct
- file reads or by handing local URIs to image or video tags, WebGL
+ file reads or by handing local URLs to image or video tags, WebGL
asset loaders, etc.</li>
<li>The files may be of arbitrary binary format.</li>
<li>On the server side, a compressed tarball will often be much
@@ -106,7 +106,7 @@
<ul>
<li>It downloads large files (>1GB) for later viewing.</li>
<li>It needs efficient seek + streaming.</li>
- <li>It must be able to hand a URI to the video tag.</li>
+ <li>It must be able to hand a URL to the video tag.</li>
<li>It should enable access to partly-downloaded files e.g. to let
you watch the first episode of the DVD even if your download didn't
complete before you got on the plane.</li>
@@ -329,22 +329,22 @@
</dd>
</dl>
</dd>
- <dt>void resolveLocalFileSystemURI ()</dt>
+ <dt>void resolveLocalFileSystemURL ()</dt>
<dd>
<p>
Allows the user to look up the Entry for a file or directory
- referred to by a local URI.
+ referred to by a local URL.
</p>
<dl class='parameters'>
- <dt>DOMString uri</dt>
+ <dt>DOMString url</dt>
<dd>
- A URI referring to a local file in a filesystem accessable via
+ A URL referring to a local file in a filesystem accessable via
this API.
</dd>
<dt>EntryCallback successCallback</dt>
<dd>
A callback that is called to report the Entry to which the
- supplied URI refers.
+ supplied URL refers.
</dd>
<dt>optional ErrorCallback errorCallback</dt>
<dd>
@@ -398,16 +398,16 @@
filesystem interface.</dd>
</dl>
</dd>
- <dt>EntrySync resolveLocalFileSystemSyncURI ()</dt>
+ <dt>EntrySync resolveLocalFileSystemSyncURL ()</dt>
<dd>
<p>
Allows the user to look up the Entry for a file or directory
- referred to by a local URI.
+ referred to by a local URL.
</p>
<dl class='parameters'>
- <dt>DOMString uri</dt>
+ <dt>DOMString url</dt>
<dd>
- A URI referring to a local file in a filesystem accessable via
+ A URL referring to a local file in a filesystem accessable via
this API.
</dd>
</dl>
@@ -419,7 +419,7 @@
that does not exist.</dd>
<dt>SECURITY_ERR</dt>
<dd>The application does not have permission to access the
- filesystem interface or the element referred to by the URI.</dd>
+ filesystem interface or the element referred to by the URL.</dd>
</dl>
</dd>
</dl>
@@ -614,10 +614,10 @@
</dd>
</dl>
</dd>
- <dt>DOMString toURI (optional DOMString mimeType)</dt>
+ <dt>DOMString toURL (optional DOMString mimeType)</dt>
<dd>
<p>
- Returns a URI that can be used to identify this entry.
+ Returns a URL that can be used to identify this entry.
Unlike the URN defined in [[!FILE-API]], it has no specific
expiration; as it describes a location on disk, it should be valid
at least as long as that location exists.
@@ -629,18 +629,18 @@
<dt>optional DOMString mimeType</dt>
<dd>
For a FileEntry, the mime type to be used to interpret the file,
- when loaded through this URI.
+ when loaded through this URL.
</dd>
</dl>
<div class='issue'>
<p>
- Do we want to spec out the URI format/scheme? It would be quite
+ Do we want to spec out the URL format/scheme? It would be quite
nice if these could be edited and manipulated easily, as with
normal filesystem paths.
</p>
<p>
- How and where can these URIs be used? Can they be interchangeable
- with online URIs for the same domain?
+ How and where can these URLs be used? Can they be interchangeable
+ with online URLs for the same domain?
</p>
<p>
Proposal currently under discussion:
@@ -648,7 +648,7 @@
<li>Use a format such as
<code>filesystem:http://example.domain/persistent-or-temporary/path/to/file.html
</code>.</li>
- <li>URIs should be usable for anything that online URIs can be
+ <li>URLs should be usable for anything that online URLs can be
used for, whether they appear in online or filesystem-resident
web pages.</li>
<li>However, they can only be used by the origin that owns the
@@ -1201,10 +1201,10 @@
out this action.</dd>
</dl>
</dd>
- <dt>DOMString toURI (optional DOMString mimeType)</dt>
+ <dt>DOMString toURL (optional DOMString mimeType)</dt>
<dd>
<p>
- Returns a URI that can be used to identify this entry.
+ Returns a URL that can be used to identify this entry.
Unlike the URN defined in [[!FILE-API]], it has no specific
expiration; as it describes a location on disk, it should be valid
at least as long as that location exists.
@@ -1216,13 +1216,13 @@
<dt>optional DOMString mimeType</dt>
<dd>
For a FileEntry, the mime type to be used to interpret the file,
- when loaded through this URI.
+ when loaded through this URL.
</dd>
</dl>
<div class='issue'>
<p>
- If we use the same opaque URI scheme as in [[!FILE-API]], users
- won't be able to edit and generate URIs themselves. On the other
+ If we use the same opaque URL scheme as in [[!FILE-API]], users
+ won't be able to edit and generate URLs themselves. On the other
hand, it would prevent us from having to go to all the trouble of
designing a new scheme, and it would simplify the use of the two
APIs together.
@@ -1592,7 +1592,7 @@
<tr>
<td>ENCODING_ERR</td><td>5</td>
<td>
- <a>user agent</a> MUST use this code when a URI supplied to
+ <a>user agent</a> MUST use this code when a URL supplied to
the API is malformed.
</td>
</tr>
Received on Wednesday, 16 March 2011 23:33:53 UTC