[Gzz-commits] manuscripts/pointers article.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/10/29 05:30:49

Modified files:
        pointers       : article.rst 

Log message:
        Start basic model

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.29 
manuscripts/pointers/article.rst:1.30
--- manuscripts/pointers/article.rst:1.29       Mon Oct 27 15:58:44 2003
+++ manuscripts/pointers/article.rst    Wed Oct 29 05:30:49 2003
@@ -275,20 +275,56 @@
 version x to a link representing version y even if version y 
 does not exist in a system yet.
 
+.. ??? XXX I don't understand the above AT ALL
 
 Basic model
 ===========
 
-- Basic model of underlying system: Only blocks
-- Benefits of that, in a nutshell
-- Reverse indexing (nicely provided through structured overlays), 
-  *define* reverse indexing
-- Def.: Pointers are abstract references that *point*
-  to different blocks (versions) over time
-- Storm is designed to be modular; different routing algorithms
-  can be used with Storm for locating data with loc.ind. ids (
-  (e.g., PAST and CFS are tightly binded to their routing
-  algorithm)
+Our goal is to build a complete system of versioning
+on top of the following primitive abstraction provided 
+by a system:
+
+Add permanent block
+    Given a bit string, adds the block into
+    the system and return a *permanent id* for
+    that exact bitstring,
+    for example a cryptographic hash of the data.
+
+Get the permanent data for a given id
+    Given a permanent id, locate and return the bitstring
+    stored with that permanent id, or inform the caller
+    that the data was not currently available.
+
+Global reverse indices
+    The ability to define (on a system-wide basis)
+    partial functions of blocks (of the data in the bitstrings)
+    and to query for the ids
+    (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.
+
+Managing where the blocks are stored is excluded
+from the scope of this abstraction. The versioning system
+must work as best it can even if only a subset of the
+blocks is available. 
+
+The benefits of starting from this basic model are numerous:
+XXX
+
+..  - Basic model of underlying system: Only blocks
+    - Benefits of that, in a nutshell
+    - Reverse indexing (nicely provided through structured overlays), 
+      *define* reverse indexing
+    - Def.: Pointers are abstract references that *point*
+      to different blocks (versions) over time
+    - Storm is designed to be modular; different routing algorithms
+      can be used with Storm for locating data with loc.ind. ids (
+      (e.g., PAST and CFS are tightly binded to their routing
+      algorithm)
 
 
 Pointer records
@@ -378,4 +414,4 @@
    may be academic articles, in which references to other articles
    are ideally to an immutable version, and in which references
    are generally not circular, making this domain map neatly
-   to the properties of hash-based referencing.
\ No newline at end of file
+   to the properties of hash-based referencing.