Clean up some remaining obsolete terminology. refs #2345

Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
Daira Hopwood 2014-12-01 22:09:27 +00:00 committed by Brian Warner
parent d3acf82776
commit eb1b51e263
2 changed files with 19 additions and 18 deletions

View File

@ -113,7 +113,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
@ -404,7 +404,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.
@ -440,11 +440,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
==========

View File

@ -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
--------
@ -164,10 +165,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.
:doc:`dirnodes` 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. :doc:`dirnodes` 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