[Gzz-commits] manuscripts/pointers article.rst

[Benja Fallenstein]

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

Modified files:
        pointers       : article.rst 

Log message:
        intro basically there, I think

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.65 
manuscripts/pointers/article.rst:1.66
--- manuscripts/pointers/article.rst:1.65       Sat Nov  1 21:21:16 2003
+++ manuscripts/pointers/article.rst    Sat Nov  1 21:43:12 2003
@@ -296,57 +296,65 @@
 
 .. Main contrib: Pointer records for implementing updating
 
-The main contribution of our paper are *pointer records*.
-A document is identified by a *pointer*, the hash of a
-public key. A pointer record is a file signed by the
-corresponding private key, containing the pointer's identity,
-the hash of a version of that document, and a timestamp.
-The newest version of a document is obtained by searching
-the peer-to-peer network for all pointer records associated
-with this pointer, and picking the newest one.
-
-This scheme is quite close to OceanStore's concept of
-*heartbeats*. However, the difference is that in OceanStore,
-heartbeats are controlled by an inner circle of servers,
-the *primary replica*, chosen by the owner of the document.
-In this scheme, when a document ceases to be maintained
-by its primary replica, it is impossible/becomes harder/*what*?XXX
-to retrieve the newest version of the document.
-
-(XXX IS THIS TRUE?)
+The main contribution of our paper are *pointer records*,
+a versioning mechanism which is similar to Oceanstore's heartbeats,
+but makes the clients download and store the pointer records
+along with the corresponding version of a document.
+If a client saves a version of a document locally, it
+stores the pointer record along with it. Thus, in our system,
+a version of a document truly remains accessible as long as
+anybody keeps a copy of it.
+
+Instead of having a primary replica, we search
+a P2P network for current pointer records
+related to a document; we pick the one with
+the most current timestamp as the version
+to show to the user. Like in OceanStore, old
+versions remain fully accessible (as long as somebody
+keeps a copy).
+
+We propose to use pointer records along with hash-based
+addressing to implement a P2P-based replacement
+for the static Web (not including dynamic pages
+generated through server-side scripting). Such a Web
+would have the benefits of semantic-free referencing--
+URIs don't have to change because of trademark conflicts
+as in DNS, for example-- but go beyond the proposal
+by Balakrishnan et.al. [XXXref], which would only
+replace DNS, but keep the centralized architecture of
+one Web server (or a single set of servers) maintained
+by the publisher of a document.
+
+Because they require no centralized version management,
+pointer records may be able to unify the namespaces
+of different P2P systems in a similar way to hash-based identifiers.
+Similar to searching different P2P networks in order
+to resolve a SHA-1 hash, you can search different networks
+to find pointer records for a document. A document
+could be originally edited in Oceanstore, then published
+in Gnutella or a DHT-based system, using an anonymized system
+like Achord [XXXref] if it contains controversial content.
 
 .. Other contribs:
    - The idea of a location-independent Web including
      location-independent version management
    - Diffs
 
-In addition to pointer records, this paper makes the following
-contributions:
-
-- Proposing a versioned location-independent Web in which not only the
-  identifiers for individual versions, but also the identifiers
-  for all versions of a document are resolved 
-  in a location-independent way;
-- Proposing an elegant way for storing only the differences
-  between versions of a document, without breaking the
-  underlying model of a datastore as a collection of
-  files identified by their hash and nothing else [XXX improve text].
+An additional contribution of this paper is XXX diffs
 
 .. Structure of this paper
 
 The remainder of this paper is structured as follows.
-In Section 2, we review related work in version management,
-and find that existing peer-to-peer versioning systems 
-do not provide the benefits of hash-based addressing.
-In Section 3, we introduce our fundamental, hash-based data model
-for a location-independent Web. In Section 4, we propose
+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 5, we introduce a scheme for storing only
+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 6, we outline solutions
+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.