mirror of
https://github.com/tahoe-lafs/tahoe-lafs.git
synced 2025-02-20 09:46:18 +00:00
Clean up some remaining obsolete terminology. refs #2345
Signed-off-by: Daira Hopwood <daira@jacaranda.org>
This commit is contained in:
parent
d3acf82776
commit
eb1b51e263
@ -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
|
||||
==========
|
||||
|
@ -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
|
||||
|
Loading…
x
Reference in New Issue
Block a user