gzz-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gzz-commits] manuscripts/pointers article.rst


From: Tuomas J. Lukka
Subject: [Gzz-commits] manuscripts/pointers article.rst
Date: Thu, 06 Nov 2003 09:26:23 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/11/06 09:26:23

Modified files:
        pointers       : article.rst 

Log message:
        Commentout

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.153 
manuscripts/pointers/article.rst:1.154
--- manuscripts/pointers/article.rst:1.153      Thu Nov  6 09:10:35 2003
+++ manuscripts/pointers/article.rst    Thu Nov  6 09:26:22 2003
@@ -13,23 +13,23 @@
 Abstract
 ========
 
-- The Web should keep previous versions as long as someone
-  is interested, even if the original publisher has lost interest
-- Wayback machine one point of failure
-- File sharing systems kind of do that
-- But you can't update files in them
-- P2P systems that do support updating don't support
-  this notion of permanence
-- We present a simple model that *does* do it
-- We present an even simpler model that it could be
-  implemented upon; the simpler model maps directly
-  to many current p2p systems
-- It can thus use different P2P networks as backends,
-  and could thus become a agreed-upon way to do
-  versioning (we believe that the current systems,
-  which require state to be kept in *one* of the networks
-  really can not)
-- Other benefits discussed
+..  - The Web should keep previous versions as long as someone
+      is interested, even if the original publisher has lost interest
+    - Wayback machine one point of failure
+    - File sharing systems kind of do that
+    - But you can't update files in them
+    - P2P systems that do support updating don't support
+      this notion of permanence
+    - We present a simple model that *does* do it
+    - We present an even simpler model that it could be
+      implemented upon; the simpler model maps directly
+      to many current p2p systems
+    - It can thus use different P2P networks as backends,
+      and could thus become a agreed-upon way to do
+      versioning (we believe that the current systems,
+      which require state to be kept in *one* of the networks
+      really can not)
+    - Other benefits discussed
 
 
 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]