[Gzz-commits] manuscripts/pointers article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Benja Fallenstein <address@hidden>      03/10/26 16:03:39

Modified files:
        pointers       : article.rst 

Log message:
        sections

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.4 
manuscripts/pointers/article.rst:1.5
--- manuscripts/pointers/article.rst:1.4        Sun Oct 26 14:19:24 2003
+++ manuscripts/pointers/article.rst    Sun Oct 26 16:03:39 2003
@@ -1,8 +1,17 @@
+============================================================================================
+Versioning in a location-independent Web: Stopping the shoulders of giants 
from rotting away
+============================================================================================
+
+(tentative title)
+
+Introduction
+============
+
 - Introduce location-independent Web idea (citing
   benefits from hash-based addressing)
 
-  - `Standing on the shoulders of giants`_: Webrotting example
-  - History of location-dependence: `TBL ref`_
+  - Standing on the shoulders of giants: Example of Web links rotting away
+  - History of location-dependence: `TBL ref`_ (like in HT'03 paper)
   - Location-independent, semantic-free, *self-verifying* 
     identifiers (ref SFR paper (Balakrishnan et.al. IPTPS'03),
     ref Walfish paper); example: hash-based (ref 
@@ -39,77 +48,89 @@
       location-independent version management
     - Non-linear versioning through obsoletion
 
-- Related work
 
-  - In this section, we summarize how existing
-    peer-to-peer systems deal with versioning.
+Related work
+============
 
-  - No updates:
+- In this section, we summarize how existing
+  peer-to-peer systems deal with versioning.
 
-    - PAST
-    - Free Haven
+- No updates:
 
-  - Centralized updates:
+  - PAST
+  - Free Haven
 
-    - SFS &c; destructive updates
-    - Publius (apparently); destructive updates
-    - Oceanstore; non-destructive, linearly versioned updates
+- Centralized updates:
+
+  - SFS &c; destructive updates
+  - Publius (apparently); destructive updates
+  - Oceanstore; non-destructive, linearly versioned updates
   
-  - Network-level destructive updates:
+- Network-level destructive updates:
 
-    - Freenet
-    - SFR (apparently)
-    - CFS
+  - Freenet
+  - SFR (apparently)
+  - CFS
   
-  - Conclusion: Doesn't provide the benefits of
-    hash-based addressing; doesn't allow accessing
-    past versions
+- Conclusion: Doesn't provide the benefits of
+  hash-based addressing; doesn't allow accessing
+  past versions
+
+
+Pointer records
+===============
+
+- Basic model of underlying system: Only blocks and reverse indexing
+  (nicely provided through DHT)
+- Key idea: Pointers are abstract references that *point*
+  to different blocks (versions) over time
+- The association between a pointer and a version is formed
+  by a special kind of block, the *pointer record*
+- Signatures
+- Timestamp for ordering the records/versions (note on problems
+  this entails-- if a computer's clock is set into future etc)
+- Implementable in other systems, too
+- 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
+
 
-- Pointer records
+Non-linear versioning for asynchronous collaboration
+====================================================
 
-  - Basic model of underlying system: Only blocks and reverse indexing
-    (nicely provided through DHT)
-  - Key idea: Pointers are abstract references that *point*
-    to different blocks (versions) over time
-  - The association between a pointer and a version is formed
-    by a special kind of block, the *pointer record*
-  - Signatures
-  - Timestamp for ordering the records/versions (note on problems
-    this entails-- if a computer's clock is set into future etc)
-  - Implementable in other systems, too
-  - Carries over the four benefits from hash-based addressing:
+- (also one person using more than one computer)
 
-    - 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
 
-- Non-linear versioning for asynchronous collaboration
+Permanent signatures
+====================
 
-  - (also one person using more than one computer)
+- To archieve the permanence alluded to above, need to
+  take into consideration stolen/cryptoanalyzed private keys
+- Simple measure: use only hashes; but obviously, we don't
+  want to do that always
+  [could do it in academic articles, though...]
+- Will now outline two schemes for permanent signatures.
+  The first comes from the literature, but has patent problems;
+  the second is a sketch of a system invented by us.
 
-- Permanent signatures
+- KASTS:
 
-  - To archieve the permanence alluded to above, need to
-    take into consideration stolen/cryptoanalyzed private keys
-  - Simple measure: use only hashes; but obviously, we don't
-    want to do that always
-    [could do it in academic articles, though...]
-  - Will now outline two schemes for permanent signatures.
-    The first comes from the literature, but has patent problems;
-    the second is a sketch of a system invented by us.
+  - ...
 
-  - KASTS:
+- Our system:
 
-    - ...
+  - ...
 
-  - Our system:
 
-    - ...
+Conclusions
+===========
 
-- Conclusions
+- To make the Web a solid foundation for standing
+  on the shoulders of giants.
 
 
-.. _Standing on the shoulders of giants: 
urn:x-storm:pointer-0.1:sep34hb5jkkzu6dqhzpt4ivymr4nzwg7:vd4chieqzy4f5pw6gl6jcpvuglxjdvy7:html
 .. _TBL ref: http://www.w3.org/DesignIssues/NameMyth.html#What