[Gzz-commits] manuscripts/storm article.rst

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Hermanni Hyytiälä <address@hidden>      03/02/04 09:08:42

Modified files:
        storm          : article.rst 

Log message:
        More fixes

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.84 manuscripts/storm/article.rst:1.85
--- manuscripts/storm/article.rst:1.84  Tue Feb  4 07:32:19 2003
+++ manuscripts/storm/article.rst       Tue Feb  4 09:08:42 2003
@@ -13,10 +13,12 @@
 future work in areas such as interoperability, scalability and security is
 identified.
 
-Keywords: data mobility, global unique identifiers, hypermedia management
-system, hyperbase, open hypermedia, structural computing, xanalogical media,
-permanent storage systems, peer-to-peer networking, distributed hash table,
-ad-hoc data mobility, mobile hypermedia
+Keywords: data mobility, ad-hoc data mobility, mobile hypermedia, 
+global unique identifiers, hypermedia management system, hyperbase, 
+open hypermedia, structural computing, xanalogical media, permanent 
+storage systems, peer-to-peer networking, structured overlay networks, 
+location inpenpendent routing, distributed hash table
+
 
 
 1. Introduction
@@ -288,7 +290,7 @@
 as regular files, but they are immutable, since any change to the
 byte sequence would change the hash (and thus create a different block).
 Mutable data structures are built on top of the immutable blocks
-(see Section 6).
+(see Section 6). 
 
 Immutable blocks has several benefits over existing data storing 
 techiques:
@@ -299,9 +301,10 @@
 [Previous sentence doesn't parse to me (what level ?) :( -Hermanni]
 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. On the other hand, several popular database management 
-systems (e.g. Lotus Notes [ref]) have complex replication schemes, which may 
-led awkward replication conflicts. 
+does not already store. On the other hand for instance, several popular 
+database management systems (e.g. Lotus Notes [ref]) have complex 
+replication schemes, which may led awkward replication conflicts, 
+because of they lack the immutable properties of data. 
 [Or does this belong to diff section ? -Hermanni]
 
 Storm blocks are MIME messages [ref MIME], i.e., objects with
@@ -317,8 +320,6 @@
     add(block)
     delete(block)
     
-[analogy to regular Hash Table/DHT ? -Hermanni]
-
 Implementations may store blocks in RAM, in individual files,
 in a Zip archive, in a database or through other means.
 We have implemented the first three (using hexadecimal
@@ -332,12 +333,14 @@
 be accessible. This makes Storm well suited as a basis
 for implementing experimental projects (such as ours).
 
-When used in a network environment, Storm ids do not provide
-a hint as to where in the network a specific block can be found.
-However, current peer-to-peer systems could be used to
-find blocks efficiently in a location independent fashion; for example, 
-Freenet [ref], recent Gnutella-based clients (e.g. Shareaza [ref]), 
-Overnet/eDonkey2000 [ref] also use SHA-1-based identifiers 
+[Example of Microsoft Word ? -Hermanni]
+
+When used in a network environment, Storm IDs do not provide
+a hint as to where a specific block is stored in the network.
+However, many existing peer-to-peer systems could be used to
+find arbitrary blocks in a location independent fashion; 
+for example, Freenet [ref], recent Gnutella-based clients 
+(e.g. Shareaza [ref]), Overnet/eDonkey2000 [ref] also use SHA-1-based 
identifiers 
 [e.g. ref: magnet uri]. Footnote:However, we have not put a network 
 implementation into regular use yet and thus can only describe our 
 design, not report on implementation experience.
@@ -356,12 +359,13 @@
 [Previous sentence doesn't parse to me: more simple :( -Hermanni]
 
 Given a peer-to-peer distribution mechanism, it would be possible
-to retrieve blocks from any peer online that has a copy
-in its cache or permanent storage. This is similar to the Squirrel
+to retrieve blocks from any participating peer online that has a copy
+in its local cache or permanent storage. This is similar to the Squirrel
 web cache [ref] [more refs? -Hermanni], but does not require trust 
 between the peers, since it is possible to check the blocks' integrity by 
using 
-cryptographic hashes. Since much-requested blocks would be 
-cached on many systems, such a network could deal with XXX 
+cryptographic hashes, as used in many peer-to-peer applications 
+(e.g. [ref: ed2k/overnet, shareaza]). Since much-requested blocks would be 
+cached on many systems, a network could deal with hotspots 
 much more easily. On the other hand, there are privacy 
 concerns with exposing one's browser cache to the outside world.
 
@@ -417,17 +421,17 @@
 in a document does not scale very well. In practice,
 characters typed in consecutively are given consecutive ids,
 such as ``...:4``, ``...:5``, ``...:6`` and so on, and
-operations are on *spans*, consecutive ranges of characters
-(``...:4-6``). In Storm, in each editor session we create a
-block with all characters entered in this session (the content type
+operations are on *spans*, i.e. consecutive ranges of characters
+(``...:4-6``) in a document. In Storm, in each editor session we 
+create a block with all characters entered in this session (the content type
 being ``text/plain``). To designate a span of characters
 from that session, we use the block's id, the offset of the first
 character, and the number of characters in the span.
 This technique was first introduced in [ref ht02 paper].
 
 In Xanadu, characters are stored to append-only *scrolls*
-when they are typed [ref]. Because of this, we call the blocks
-containing the actual characters *scroll blocks*. The documents
+when they are typed [ref]. Because of this, in Storm, we call the 
+blocks containing the actual characters *scroll blocks*. The documents
 do not actually contain the characters; instead, they are
 *virtual files* containing span references as described above.
 To show a document, the scroll blocks it references are loaded
@@ -459,7 +463,7 @@
 systems that allow range queries, such as skip graphs [ref] 
 and skipnet [ref], may prove useful.
 
-[This might be relevant:
+[This might be relevant also:
 http://www.hpl.hp.com/techreports/2002/HPL-2002-209.pdf
 -Hermanni]
 
@@ -481,7 +485,7 @@
 Storm provides a general API for indexing blocks in
 application-specific ways. We have implemented indexing
 on a local machine, but the interface is designed so that
-implementation on top of a distributed hashtable
+implementation on top of networking overlay (e.g. distributed hashtable)
 will be trivial.
 
 [Benja, this might be useful for defining Storm APIs for DHTs etc: 
@@ -493,6 +497,8 @@
 to index blocks provide the following callback
 to a Storm pool::
 
+[What is mapping ? We should explain this :) -Hermanni]
+
     getMappings(block) -> set of (key, value) pairs
 
 This callback processes a block and returns a set of mappings
@@ -513,10 +519,10 @@
 As an example, the ``getMappings()`` method of our Xanalogical 
 storage implementation will, for a block containing a document,
 collect all the spans in a document, and return mappings
-from their scroll blocks' ids to the spans and their positions
+from their scroll blocks' IDs to the spans and their positions
 in the document. When we want to find the transclusions of
-a span, we ``get()`` the mappings for the id of that span's
-scroll block, and load the document blocks referenced
+a span, we use ``get()`` to get the mappings for the ID of 
+that span's scroll block, and load the document blocks referenced
 by the mappings.
 
 In a networked implementation, each peer is responsible