[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/15 09:10:34

Modified files:
        storm          : article.rst 

Log message:
        more refactoring

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.157 manuscripts/storm/article.rst:1.158
--- manuscripts/storm/article.rst:1.157 Sat Feb 15 09:09:28 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 09:10:33 2003
@@ -476,7 +476,7 @@
 In Storm, all data is stored
 as *blocks*, byte sequences identified by a SHA-1 
 cryptographic content hash [fips-sha-1]_. 
-Being purely a function of a block's content, block ids
+Purely a function of a block's content, block ids
 are completely independent of network location.
 Blocks have a similar granularity
 as regular files, but they are immutable, since any change to the
@@ -491,16 +491,9 @@
 the cryptographic hash in the identifier. Therefore, we can 
 safely download blocks from an untrusted peer.
 
-While digital signatures also allow for self-certifying identifiers
-(the identifier could contain a public key, and we could check 
-the signature after downloading a block),
-they raise the need for a public-key infrastructure (PKI)
-and for a timestamping mechanism in order to be reliable
-for more than a short time.
-
 When we make a reference to a block, we can be sure
 that even the original author of the target will not be able 
-to change it (contrast this with a signature-based scheme). 
+to change it (unlike with e.g. digital signatures).
 For example, if a newspaper refers to a letter
 to the editor this way, the letter's sender won't be able to change 
 the reference into an advertisement for a pornographic web page.
@@ -509,9 +502,6 @@
 never necessary to check for new versions of blocks. It is easy
 to replicate data between systems: A replica of a block never
 needs to be updated; cached copies can be kept as long as desired.
-When a document is replicated, different versions of it can
-coexist on the same system without naming conflicts, since
-each version will be stored in its own block with its own id.
 
 If peers make the blocks in their caches available on the network,
 the flash crowd problem could be alleviated: The more users
@@ -525,7 +515,10 @@
 To replicate all data from computer A
 on computer B, it suffices to copy all blocks from A to B that B
 does not already store. This can be done through a simple 'copy'
-command. In contrast, a system based on mutable resources
+command. Different versions of a single document
+can coexist on the same system without naming conflicts, since
+each version will be stored in its own block with its own id.
+In contrast, a system based on mutable resources
 has to use more advanced schemes, for example merging the changes
 done to a document at A or B. (Merging is still be necessary
 when a user wants to incorporate a set of changes, but not
@@ -542,7 +535,7 @@
 permanently downloaded to the local harddisk, it can be found
 by a browser just as data from the network. This is convenient 
 for offline browsing, for example in mobile environments:
-After a document has been downloaded, links to it will *never*
+After a block has been downloaded, references to it will *never*
 cease to work, online or offline.
 
 .. tried to think this a bit, as 'never' is always a strong word.
@@ -559,6 +552,9 @@
    (or confused, if diff from A,B1.0->1.1 was so major that how A1.1 links to
    B1.1 does not make any sense when the user ends up in 1.0 instead?)
    -- antont
+
+.. Changed to read 'block.' That blocks are immutable should be clear
+   at this point ;-) -b
 
 Thirdly, immutable blocks increase *reliability*. 
 When saving a document, an application will only *add* blocks,