[Gzz-commits] manuscripts/pointers article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/11/03 11:56:33

Modified files:
        pointers       : article.rst 

Log message:
        more pointer records section

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.92 
manuscripts/pointers/article.rst:1.93
--- manuscripts/pointers/article.rst:1.92       Mon Nov  3 11:34:52 2003
+++ manuscripts/pointers/article.rst    Mon Nov  3 11:56:33 2003
@@ -227,7 +227,7 @@
 Pointer records
 ===============
 
-In this section, we present our main contribution: a way
+In this section, we discuss our main contribution: a way
 to implement a persistent, distributed versioning
 system with no centralized components. 
 
@@ -259,6 +259,9 @@
 The pointer record with the most current timestamp gives
 the current version of the document. All available records
 taken together form a full history of the document.
+The list of available records can be obtained through a
+peer-to-peer network; this could be a DHT, a flooding broadcasting
+network like Gnutella [XXXref], or any other P2P architecture.
 
 In addition to the above information, a pointer record
 may contain a list of versions that the current version
@@ -268,38 +271,32 @@
 The resulting directed acyclic graph can be used to detect
 situations where a document has been concurrently edited
 on two different machines, requiring a merge.
+(This approach was introduced in [fallenstein03storm]_.)
 
 Contrary to other systems, our
 system treats pointer records as *first-class citizens*;
 pointer records
 are treated just as normal data files 
-and may reside on any host.
+and may reside on (and be downloaded from) any host.
 
+For example, a file-sharing system could, for every versioned 
+file ``f``, store two companion file ``f.version`` 
+and ``f.charter``, containing the charter and pointer record 
+associated with this version of this file. The file-sharing 
+application could then serve this information to other peers
+searching for versions of this document. It could also use it
+to notify the user when new versions of the file become available.
 
-..  - In this section, we discuss a particular way
-      of implementing pointers (this is our main contribution)
-    - The association between a pointer and a version is formed
-      by a special kind of block, the *pointer record*
-    - A pointer record is like a heartbeat in OceanStore;
-      difference: we do it within the basic framework of sets of blocks.
+.. XXX move previous paragraph to Applications? but it'd be nice
+   to show here how this relates to existing systems. HMMM.
 
-      - Signatures
-      - Timestamp for ordering the records/versions (note on problems
-       this entails-- if a computer's clock is set into future etc)
-      - explicit obsoletion of pointers
-
-
-    - Carries over the four benefits from hash-based addressing:
+..  - Carries over the four benefits from hash-based addressing:
 
       - Version references movable between servers
       - Past versions accessible as long as anyone keeps a copy
       - Load balancing (download the pointer record from whoever has it)
       - Can use one addressing scheme for *updateable* information,
        searching different networks for versions
-
-    - Implementable in any system providing the above features, 
-      too [XXX is this still a point
-      given that OceanStorm does something similar?] think 
 
 
 Primitive block storage abstraction