/[gzz]/manuscripts/pointers/article.rst
ViewVC logotype

Diff of /manuscripts/pointers/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.4 by benja, Sun Oct 26 19:19:24 2003 UTC revision 1.5 by benja, Sun Oct 26 21:03:39 2003 UTC
# Line 1  Line 1 
1    ============================================================================================
2    Versioning in a location-independent Web: Stopping the shoulders of giants from rotting away
3    ============================================================================================
4    
5    (tentative title)
6    
7    Introduction
8    ============
9    
10  - Introduce location-independent Web idea (citing  - Introduce location-independent Web idea (citing
11    benefits from hash-based addressing)    benefits from hash-based addressing)
12    
13    - `Standing on the shoulders of giants`_: Webrotting example    - Standing on the shoulders of giants: Example of Web links rotting away
14    - History of location-dependence: `TBL ref`_    - History of location-dependence: `TBL ref`_ (like in HT'03 paper)
15    - Location-independent, semantic-free, *self-verifying*    - Location-independent, semantic-free, *self-verifying*
16      identifiers (ref SFR paper (Balakrishnan et.al. IPTPS'03),      identifiers (ref SFR paper (Balakrishnan et.al. IPTPS'03),
17      ref Walfish paper); example: hash-based (ref      ref Walfish paper); example: hash-based (ref
# Line 39  Line 48 
48        location-independent version management        location-independent version management
49      - Non-linear versioning through obsoletion      - Non-linear versioning through obsoletion
50    
 - Related work  
51    
52    - In this section, we summarize how existing  Related work
53      peer-to-peer systems deal with versioning.  ============
54    
55    - No updates:  - In this section, we summarize how existing
56      peer-to-peer systems deal with versioning.
57    
58      - PAST  - No updates:
     - Free Haven  
59    
60    - Centralized updates:    - PAST
61      - Free Haven
62    
63      - SFS &c; destructive updates  - Centralized updates:
64      - Publius (apparently); destructive updates  
65      - Oceanstore; non-destructive, linearly versioned updates    - SFS &c; destructive updates
66      - Publius (apparently); destructive updates
67      - Oceanstore; non-destructive, linearly versioned updates
68        
69    - Network-level destructive updates:  - Network-level destructive updates:
70    
71      - Freenet    - Freenet
72      - SFR (apparently)    - SFR (apparently)
73      - CFS    - CFS
74        
75    - Conclusion: Doesn't provide the benefits of  - Conclusion: Doesn't provide the benefits of
76      hash-based addressing; doesn't allow accessing    hash-based addressing; doesn't allow accessing
77      past versions    past versions
78    
79    
80    Pointer records
81    ===============
82    
83    - Basic model of underlying system: Only blocks and reverse indexing
84      (nicely provided through DHT)
85    - Key idea: Pointers are abstract references that *point*
86      to different blocks (versions) over time
87    - The association between a pointer and a version is formed
88      by a special kind of block, the *pointer record*
89    - Signatures
90    - Timestamp for ordering the records/versions (note on problems
91      this entails-- if a computer's clock is set into future etc)
92    - Implementable in other systems, too
93    - Carries over the four benefits from hash-based addressing:
94    
95      - Version references movable between servers
96      - Past versions accessible as long as anyone keeps a copy
97      - Load balancing (download the pointer record from whoever has it)
98      - Can use one addressing scheme for *updateable* information,
99        searching different networks for versions
100    
101    
102  - Pointer records  Non-linear versioning for asynchronous collaboration
103    ====================================================
104    
105    - Basic model of underlying system: Only blocks and reverse indexing  - (also one person using more than one computer)
     (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:  
106    
     - 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  
107    
108  - Non-linear versioning for asynchronous collaboration  Permanent signatures
109    ====================
110    
111    - (also one person using more than one computer)  - To archieve the permanence alluded to above, need to
112      take into consideration stolen/cryptoanalyzed private keys
113    - Simple measure: use only hashes; but obviously, we don't
114      want to do that always
115      [could do it in academic articles, though...]
116    - Will now outline two schemes for permanent signatures.
117      The first comes from the literature, but has patent problems;
118      the second is a sketch of a system invented by us.
119    
120  - Permanent signatures  - KASTS:
121    
122    - 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.  
123    
124    - KASTS:  - Our system:
125    
126      - ...    - ...
127    
   - Our system:  
128    
129      - ...  Conclusions
130    ===========
131    
132  - Conclusions  - To make the Web a solid foundation for standing
133      on the shoulders of giants.
134    
135    
 .. _Standing on the shoulders of giants: urn:x-storm:pointer-0.1:sep34hb5jkkzu6dqhzpt4ivymr4nzwg7:vd4chieqzy4f5pw6gl6jcpvuglxjdvy7:html  
136  .. _TBL ref: http://www.w3.org/DesignIssues/NameMyth.html#What  .. _TBL ref: http://www.w3.org/DesignIssues/NameMyth.html#What

Legend:
Removed from v.1.4  
changed lines
  Added in v.1.5

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26