From: Daira Hopwood Date: Mon, 1 Dec 2014 22:09:27 +0000 (+0000) Subject: Clean up some remaining obsolete terminology. refs #2345 X-Git-Url: https://git.rkrishnan.org/?a=commitdiff_plain;h=refs%2Fpull%2F131%2Fhead;p=tahoe-lafs%2Ftahoe-lafs.git Clean up some remaining obsolete terminology. refs #2345 Signed-off-by: Daira Hopwood --- diff --git a/docs/specifications/dirnodes.rst b/docs/specifications/dirnodes.rst index d3a1b5b6..92a69de0 100644 --- a/docs/specifications/dirnodes.rst +++ b/docs/specifications/dirnodes.rst @@ -114,7 +114,7 @@ dirnodes is such that read-only access is transitive: i.e. if you grant Bob read-only access to a parent directory, then Bob will get read-only access (and *not* read-write access) to its children. -Relative to the previous "vdrive-server" based scheme, the current +Relative to the previous "vdrive server"-based scheme, the current distributed dirnode approach gives better availability, but cannot guarantee updateness quite as well, and requires far more network traffic for each retrieval and update. Mutable files are somewhat less available than @@ -407,7 +407,7 @@ storage index, but do *not* include the readkeys or writekeys, so the repairer does not get to read the files or directories that it is helping to keep alive. -After each change to the user's vdrive, the client creates a manifest and +After each change to the user's file store, the client creates a manifest and looks for differences from their previous version. Anything which was removed prompts the client to send out lease-cancellation messages, allowing the data to be deleted. @@ -443,11 +443,11 @@ shared-with-bob/ or subdir2/. .. _`Prime Coordination Directive`: ../write_coordination.rst A suitable UI needs to be created to allow users to easily perform this -sharing action: dragging a folder their vdrive to an IM or email user icon, -for example. The UI will need to give the sending user an opportunity to -indicate whether they want to grant read-write or read-only access to the -recipient. The recipient then needs an interface to drag the new folder into -their file store and give it a home. +sharing action: dragging a folder from their file store to an IM or email +user icon, for example. The UI will need to give the sending user an +opportunity to indicate whether they want to grant read-write or read-only +access to the recipient. The recipient then needs an interface to drag the +new folder into their file store and give it a home. Revocation ========== diff --git a/docs/specifications/uri.rst b/docs/specifications/uri.rst index f6efc6e8..acf10517 100644 --- a/docs/specifications/uri.rst +++ b/docs/specifications/uri.rst @@ -41,9 +41,10 @@ herein. File URIs ========= -The lowest layer of the Tahoe architecture (the "grid") is reponsible for -mapping URIs to data. This is basically a distributed hash table, in which -the URI is the key, and some sequence of bytes is the value. +The lowest layer of the Tahoe architecture (the "key-value store") is +reponsible for mapping URIs to data. This is basically a distributed +hash table, in which the URI is the key, and some sequence of bytes is +the value. There are two kinds of entries in this table: immutable and mutable. For immutable entries, the URI represents a fixed chunk of data. The URI itself @@ -53,10 +54,10 @@ to locate and download that data from the grid at some time in the future. For mutable entries, the URI identifies a "slot" or "container", which can be filled with different pieces of data at different times. -It is important to note that the "files" described by these URIs are just a -bunch of bytes, and that **no** filenames or other metadata is retained at -this layer. The vdrive layer (which sits above the grid layer) is entirely -responsible for directories and filenames and the like. +It is important to note that the values referenced by these URIs are just +sequences of bytes, and that **no** filenames or other metadata is retained at +this layer. The file store layer (which sits above the key-value store layer) +is entirely responsible for directories and filenames and the like. CHK URIs -------- @@ -168,10 +169,10 @@ structure to provide mutable file access. Directory URIs ============== -The grid layer provides a mapping from URI to data. To turn this into a graph -of directories and files, the "vdrive" layer (which sits on top of the grid -layer) needs to keep track of "directory nodes", or "dirnodes" for short. -dirnodes.rst_ describes how these work. +The key-value store layer provides a mapping from URI to data. To turn this +into a graph of directories and files, the "file store" layer (which sits on +top of the key-value store layer) needs to keep track of "directory nodes", +or "dirnodes" for short. dirnodes.rst_ describes how these work. Dirnodes are contained inside mutable files, and are thus simply a particular way to interpret the contents of these files. As a result, a directory