[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/09 05:33:17

Modified files:
        storm          : article.rst 

Log message:
        Apply fixes to article, too

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.122 manuscripts/storm/article.rst:1.123
--- manuscripts/storm/article.rst:1.122 Sun Feb  9 04:40:51 2003
+++ manuscripts/storm/article.rst       Sun Feb  9 05:33:17 2003
@@ -63,7 +63,7 @@
 Dangling links and keeping track of alternative versions. 
 Resolvable location-independent identifiers
 make these issues much easier to deal with, since data
-can be recognized whereever it is moved [#]_. 
+can be recognized wherever it is moved [#]_. 
 
 .. [#] It might be more appropriate to speak about *resources*
    and *references* instead of *documents* and *links*, but
@@ -91,7 +91,7 @@
 
 Location-independent identifiers for documents 
 make such a system unnecessary; a peer-to-peer lookup system 
-can find documents whereever they are moved.
+can find documents wherever they are moved.
 Such a system also works for data not publicized on the Internet.
 For example, if one email has a document attached to it, and another email
 links to this document, an index of locally stored documents
@@ -309,7 +309,7 @@
 between points in the key space (e.g. numeric, XOR); the peer
 responsible for a hashtable key, then, is the one that is *closest*
 to it in the key space, according to the distance metric.
-A peer, then, is analogous to a hashtable bucket.
+A DHT peer is roughly analogous to a hashtable bucket.
 Queries are routed to the overlay network, each hop bringing
 them closer to its destination in key space, until they reach
 the peer responsible for them.