[Gzz-commits] manuscripts/pointers article.rst docutils.conf

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/01 21:49:37

Modified files:
        pointers       : article.rst docutils.conf 

Log message:
        restructure (text not yet changed for it to make sense)

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/pointers/article.rst.diff?tr1=1.66&tr2=1.67&r1=text&r2=text
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/pointers/docutils.conf.diff?tr1=1.2&tr2=1.3&r1=text&r2=text

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.66 
manuscripts/pointers/article.rst:1.67
--- manuscripts/pointers/article.rst:1.66       Sat Nov  1 21:43:12 2003
+++ manuscripts/pointers/article.rst    Sat Nov  1 21:49:37 2003
@@ -345,17 +345,14 @@
 .. Structure of this paper
 
 The remainder of this paper is structured as follows.
-In Section 2, we introduce our fundamental, hash-based data model
-for a location-independent Web. In Section 3, we propose
-a versioning system built on top of this data model.
+In Section 2, we introduce pointer records.
+In Section 3, we propose a simple, hash-based data model
+that can be used by P2P Web servers and clients.
 In Section 4, we introduce a scheme for storing only
-the differences between versions that works with our
-basic data model, making the storage of past versions
-more economical. In Section 5, we outline solutions
-to the permanency issues raised by the use of 
-cryptographic keys (which may be stolen or lost).
-In Section 6 we discuss our implemenation, and
-Section 7 concludes.
+the differences between versions, built on our basic
+data model. In Section 5 we discuss other possible applications
+of pointer records, and Section 6 gives an overview of our
+implementation. Section 7 concludes.
 
 
 
@@ -432,68 +429,6 @@
 
    .. ??? XXX I don't understand the above AT ALL
 
-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:
-
-Add permanent block
-    Given a bit string and a MIME type,
-    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:
-
-- simple to implement - existing models cover this well
-
-- can be made to work with peers that join and leave small
-  ad hoc networks often (and the global "net" less often)
-
-- robust - all state of the system is in the blocks
-
-In this framework, we shall define a system of *pointers*:
-some types of identifiers that refer to a block but whose
-referent may be changed. In the following Sections, we show
-how a reasonably efficient system can be constructed
-using only the primitive datablock model given above.
-
-..  - 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
 ===============
@@ -571,6 +506,70 @@
       too [XXX is this still a point
       given that OceanStorm does something similar?] think 
 
+
+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:
+
+Add permanent block
+    Given a bit string and a MIME type,
+    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:
+
+- simple to implement - existing models cover this well
+
+- can be made to work with peers that join and leave small
+  ad hoc networks often (and the global "net" less often)
+
+- robust - all state of the system is in the blocks
+
+In this framework, we shall define a system of *pointers*:
+some types of identifiers that refer to a block but whose
+referent may be changed. In the following Sections, we show
+how a reasonably efficient system can be constructed
+using only the primitive datablock model given above.
+
+..  - 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)
+
+
 Diffs
 =====
 
@@ -580,6 +579,12 @@
   takes 500 KB)
 - old idea: storing only differences
 - XXX
+
+
+Applications
+============
+
+XXX
 
 
 Implementation
Index: manuscripts/pointers/docutils.conf
diff -u manuscripts/pointers/docutils.conf:1.2 
manuscripts/pointers/docutils.conf:1.3
--- manuscripts/pointers/docutils.conf:1.2      Thu Oct 30 03:41:50 2003
+++ manuscripts/pointers/docutils.conf  Sat Nov  1 21:49:37 2003
@@ -1,8 +1,13 @@
-#$Id: docutils.conf,v 1.2 2003/10/30 08:41:50 tjl Exp $
+#$Id: docutils.conf,v 1.3 2003/11/02 02:49:37 benja Exp $
 
 [options]
 
-stylesheet-path = article.css
+stylesheet-path: article.css
+
+source-link: 
+datestamp: 
+generator: 
+
 
 # LaTeX
 documentclass: article