[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/15 10:50:15

Modified files:
        storm          : article.rst 

Log message:
        shorten

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/storm/article.rst.diff?tr1=1.166&tr2=1.167&r1=text&r2=text

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.166 manuscripts/storm/article.rst:1.167
--- manuscripts/storm/article.rst:1.166 Sat Feb 15 10:35:04 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 10:50:15 2003
@@ -792,8 +792,7 @@
 6.1. Pointers: implementing mutable resources
 ---------------------------------------------
 
-In Storm, *pointers* are used to implement mutable resources.
-A pointer is a globally unique identifier (usually created randomly)
+A Storm pointer is a globally unique identifier (usually created randomly)
 that can refer to different blocks over time. A block a pointer
 points to is called the pointer's *target* (Fig. [ref-storm_pointers]_).
 
@@ -801,8 +800,7 @@
 a *pointer block*, representing an assertion like *pointer P targets
 block B*. To find the target of pointer P, Storm searches for
 blocks of this form. This is one application of Storm
-indexing (Section 5): Keeping an index of all pointer blocks
-about pointer ``P``, we can quickly find out the current one.
+indexing (Section 5), using P as the index key.
 
 .. uml:: storm_pointers
     :caption: The Storm pointer system
@@ -849,34 +847,24 @@
 alternative versions have been consolidated, a pointer block
 obsoleting both consolidated previous versions is created.
 
-In a multi-user environement, we generally want only
-one user or group of users to be able to produce new
-official versions of a given document (an exception may
-be wikis, which are collaboratively edited by anyone
-interested [leuf01wiki]_). It is not yet clear how to do this.
+In a multi-user environment, we usually want only one user
+or group to be able to publish official versions a document.
+It is not yet clear how to do this.
 Signing pointer blocks digitally may be sensible, but
 digital signatures require a public key infrastructure
-and a trusted timestamping mechanism [#]_, which
-is hardly feasible for a system intended to be used
+and a trusted timestamping mechanism, which
+are hardly feasible for a system intended to be used
 for off-line as well as on-line work.
 For long-term publishing, one-time signatures have been
-found useful [anderson98erl]_. For the time being, the pointer mechanism
-works only in trusted Storm pools (Section 4), e.g.
+found useful [anderson98erl]_. Currently, the pointer mechanism
+works only in trusted Storm pools, e.g.
 in a workgroup collaborating on a set of documents.
 
-.. [#] Without timestamps, digital signatures are only valid
-   for a limited time [ref].
-
 The ability to retain multiple 'current' versions of a document
 can be useful, for example when there is no time to consolidate
-changes at the time of synchronization.
-Yet, it is decidedly inconvenient when every time one opens a document,
-the computer pops up a little window saying, "There are currently
-three different versions of this resource. Which one would you like
-to open?" Overcoming this problem will be an important issue
-as the system matures. A possible way to alleviate this problem
-would be to allow prioritizing alternate versions based on metadata,
-for example opening an official or original version automatically
+changes at the time of synchronization. However, we need
+to choose one such version when loading the document.
+For example, we could open an official or original version automatically
 if one exists.
 
 While we think that alternative current versions are useful for
@@ -906,34 +894,9 @@
 each with only small changes. Instead, we use the well-known
 technique of storing only the differences between versions.
 
-A simplistic scheme to implement this atop block storage would be
-to form a block by storing the difference to the previous version
-together with the id of the block representing that version
-(indeed, this was the way our first implementation worked).
-To load a version, it is then necessary to process 
-all the differences in order. This scheme makes it extremely
-difficult to remove an older version: The chain of versions
-leading up to the current one would be broken if any
-previous version were deleted. 
-
-Additionally, many versioning systems (e.g. CVS [cvs]_)
-store the current version as well as the differences,
-enabling them to retrieve the current version quickly and compute
-recent versions by applying the differences 'backwards,'
-starting from the current version. If this technique were applied
-in the simplistic scheme above, there would be no guarantee
-that the resulting version would really be the version referred to:
-The cryptographic hashes only guarantee this when all of the
-differences are processed.
-
-The root of these difficulties is that we refer to a version
-by the hash of a data record referencing the previous version,
-represented as a hash of a data record referencing the version
-before that, and so on. 
-
-To solve this problem, in our current
-design we refer to a version simply by the hash of that version--
-that is, the hash of a block containing that version.
+Even though we use diffs,
+we *pretend* to store whole versions: We refer to a version
+by the id of a block containing it.
 However, we do not necessarily store this block,
 even though we refer to it. Instead, we may create a *diff block*,
 containing a difference and the ids of the versions this