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: Wed, 29 Oct 2003 07:39:01 -0500

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/10/29 07:39:01

Modified files:
        pointers       : article.rst 

Log message:
        Some more points

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

Patches:
Index: manuscripts/pointers/article.rst
diff -u manuscripts/pointers/article.rst:1.34 
manuscripts/pointers/article.rst:1.35
--- manuscripts/pointers/article.rst:1.34       Wed Oct 29 07:32:19 2003
+++ manuscripts/pointers/article.rst    Wed Oct 29 07:39:01 2003
@@ -365,6 +365,8 @@
 system relying only on the abstraction presented
 in the previous section.
 
+
+
 ..  - In this section, we discuss a particular way
       of implementing pointers (this is our main contribution)
     - The association between a pointer and a version is formed
@@ -375,9 +377,9 @@
       - Signatures
       - Timestamp for ordering the records/versions (note on problems
        this entails-- if a computer's clock is set into future etc)
+      - explicit obsoletion of pointers
+
 
-    - Implementable in other systems, too [XXX is this still a point
-      given that OceanStorm does something similar?]
     - Carries over the four benefits from hash-based addressing:
 
       - Version references movable between servers
@@ -386,6 +388,9 @@
       - Can use one addressing scheme for *updateable* information,
        searching different networks for versions
 
+    - Implementable in any system providing the above features, 
+      too [XXX is this still a point
+      given that OceanStorm does something similar?] think 
 
 Diffs
 =====
@@ -419,8 +424,22 @@
   - ...
 
 
+Implementation
+==============
+
+- ?
+
 Conclusions
 ===========
+
+- COUNTERARGUMENTS THAT NEED TO BE ADDRESSED:
+    - efficiency? Storing lots of versions could get inefficient,
+      especially on the part of indexing the pointers in the system.
+      If there are 1000 000 000 or more pointer blocks of a single pointer,
+      what part of the system fails, if any?
+       - will be there only if someone *wants* to store those versions
+         unwanted versions get purged
+    - spamming with new versions (only author due to DS, but still)
 
 - XXX
 - We have presented a peer-to-peer infrastructure that...with 
location-independent




reply via email to

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