[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/04 05:24:05

Modified files:
        pointers       : article.rst 

Log message:
        Intro

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.122 
manuscripts/pointers/article.rst:1.123
--- manuscripts/pointers/article.rst:1.122      Tue Nov  4 05:03:27 2003
+++ manuscripts/pointers/article.rst    Tue Nov  4 05:24:04 2003
@@ -172,14 +172,13 @@
 has fallen off the Web. "If I have seen further it is by standing
 on the shoulders of giants;" but how can we do that today,
 if the shoulders keep rotting away?
+The Internet Archive's Wayback Machine [waybackmachine]_
+alleviates these concerns somewhat, but it introduces
+a single point of failure-- and censorship-- for the *entire* Web!
 
 .. [#rtg-links] ``http://www.seds.org/spaceviews/cassini/ rtgpages.html``.
    All links dereferenced on October 27th, 2003.
 
-(The Internet Archive's Wayback Machine [waybackmachine]_
-alleviates these concerns, but it introduces
-a single point of failure-- and censorship-- for the *entire* Web!)
-
 .. <<<We don't propose that every byte of information ever published
    on the Web has to be kept around forever. However,
    we do believe that as long as someone does keep a copy,
@@ -194,39 +193,41 @@
    Web cannot archieve, through the novel combination of
    network transparency and location independence (ref ourselves).
 
-The main contribution of our paper are *pointer records*,
+The main contribution of this paper is the use of *pointer records*,
 a versioning mechanism which is similar to OceanStore's heartbeats,
-but makes the clients download and store the pointer records
+but allows the clients to 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.
-
+If a client caches a version of a document locally, it
+stores the pointer record along with it. 
 Instead of having a primary replica, we search
-a P2P network for current pointer records
+the 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).
+to show to the user by default; old versions 
+remain equally accessible 
+as long as
+anybody keeps a copy.
+
+..  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
+for the 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. [balakrishnan03semanticfree]_, which would only
-replace DNS, but keep the centralized architecture of
+by Balakrishnan et.al. [balakrishnan03semanticfree]_, 
+for replacing DNS but keeping the centralized architecture of
 one Web server (or a single set of servers) maintained
 by the publisher of a document.
 
 The remainder of this paper is structured as follows.
 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 3, we discuss the minimal hash-based data model required
+for implementing pointers.
 In Section 4 we discuss other possible applications
 of pointer records, and Section 5 gives an overview of our
 implementation. Section 6 concludes.