[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz-commits] manuscripts/storm article.rst
From: |
Benja Fallenstein |
Subject: |
[Gzz-commits] manuscripts/storm article.rst |
Date: |
Sat, 15 Feb 2003 09:10:34 -0500 |
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,
- [Gzz-commits] manuscripts/storm article.rst, (continued)
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/02/14
- [Gzz-commits] manuscripts/storm article.rst, Hermanni Hyytiälä, 2003/02/14
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/14
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/14
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/14
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst,
Benja Fallenstein <=
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Benja Fallenstein, 2003/02/15
- [Gzz-commits] manuscripts/storm article.rst, Toni Alatalo, 2003/02/15