[Gzz-commits] manuscripts/pointers article.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/11/03 09:18:48

Modified files:
        pointers       : article.rst 

Log message:
        Sync

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.87 
manuscripts/pointers/article.rst:1.88
--- manuscripts/pointers/article.rst:1.87       Mon Nov  3 09:08:46 2003
+++ manuscripts/pointers/article.rst    Mon Nov  3 09:18:47 2003
@@ -229,27 +229,39 @@
 
 This Section gives our main contribution: a way
 to implement a persistent, distributed versioning
-system relying only on the block abstraction presented
-in the previous section.
+system with no centralized components. 
 
-Our system is based on adding *pointer record* 
-blocks to the system. Pointer record blocks are similar 
-to Oceanstore's heartbeats but the important difference
-in our system is that they are also represented as simple 
-data blocks.
+Our system is based on *pointer record* 
+data blocks - small files that, like Oceanstore's heartbeats,
+state that a given version of a given pointer points to
+a given hash, with a digital signature.
+However, contrary to other systems, our
+system treats pointer records as *first-class citizens*;
+pointer records
+are treated just as normal data blocks/files 
+and may reside on any host.
 
+Below, we shall use |PointerID| and |BlockID| for identifiers
+of blocks and pointers, respectively.
 
-The PointerID is a combination of a public key of the
+The |PointerID| is a combination of a public key of the
 owner of the pointer (possibly a certificate)
-and an identifier. The association of the PointerID to
-a particular data block is specified by adding a 
-pointer block into the system, which contains
+and an identifier (usually a semantic-free random bitstring). 
+The association of the PointerID to
+a particular data block is specified by adding 
+to the system a pointer data block which contains
+
+..  |PointerID| raw:: latex
+    {\sf PointerID}
+
+..  |BlockID| raw:: latex
+
+    {\sf BlockID}
 
 - the PointerID
-- the pointee: a block ID
-- a way to sequence pointer blocks: either a
-  timestamp, 
-  a list of pointer blocks *obsoleted* by this pointer block, or both
+- the current pointee: a block ID
+- a timestamp
+- (optionally) a list of pointer blocks *obsoleted* by this pointer block
 - a digital signature of all the above data, using the private
   key corresponding to the public key in the PointerID 
 
@@ -304,9 +316,12 @@
 Primitive block storage abstraction
 ===================================
 
-Our goal is to build a complete system of versioning
-on top of the following primitive abstraction provided 
-by a system:
+In this Section, we shall 
+discuss the requirements for using pointer blocks
+
+explicitly state the capabilities
+that our pointer scheme requires from the underlying system.
+
 
 Add permanent block
     Given a bit string and a MIME type,
@@ -327,10 +342,10 @@
     (and thus the data)
     of the blocks with the given values for the functions.
 
-For scalability, the ability to also define another 
-function, which takes a set of blocks and determines which
-of the blocks are "relevant" locally on each peer can yield
-great improvements.
+    For scalability, the ability to also define another 
+    function, which takes a set of blocks and determines which
+    of the blocks are "relevant" locally on each peer can yield
+    great improvements.
 
 Managing where the blocks are stored is excluded
 from the scope of this abstraction. The versioning system