[Gzz-commits] manuscripts/storm article.rst

[Hermanni Hyytiälä]

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

Modified files:
        storm          : article.rst 

Log message:
        Misc updates

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.76 manuscripts/storm/article.rst:1.77
--- manuscripts/storm/article.rst:1.76  Mon Feb  3 05:01:54 2003
+++ manuscripts/storm/article.rst       Mon Feb  3 08:40:20 2003
@@ -300,19 +300,18 @@
 never overwrite existing data. When a bug causes an application
 to write malformed data, only the changes from one session
 will be lost; the previous version of the data will still
-be accessible. (Footnote: This makes Storm well suited as a basis
-for implementing experimental projects (such as ours).)
+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 distributed fashion; for example, 
-Freenet [ref], a few recent Gnutella clients (e.g. Shareaza [ref]), 
+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 
-[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.)
+[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.
 We discuss peer-to-peer implementations in Section 7, below.
 
 The immutability of blocks should make caching trivial, since it is
@@ -362,7 +361,7 @@
 that the link connects. Xanalogical links are external and bidirectional.
 
 .. [#] Xanalogical storage is not limited to text. We speak about
-   *characters* because it simplifies the explanation; pixels
+   *characters* because it simplifies the explanation; picture's pixels
    or frames of video could be substituted.
 
 In addition to content links, xanalogical storage keeps an index of
@@ -376,13 +375,13 @@
 queries the index for other documents containing this character,
 and shows them as transclusions. Resolving links is a multi-step process.
 Each link is modeled as two collections of characters: the two
-endpoints of the link. To show links to a document,
+endpoints of the link. To show links to a specific document,
 the system firstly uses the link index to find links
-to each character in the documment. Secondly, for each link,
+to each character in the document. Secondly, for each link,
 it looks at the *other* set of characters in the link-- the target
 of the link, if the original character was the source, and vice versa.
 Thirdly, it looks for documents containing these target characters.
-This way, even if both the source and target cjaracters of the link 
+This way, even if both the source and target characters of the link 
 are moved to a different document, the link stays connected to them.
 
 Of course, doing any expensive operation for *every* character 
@@ -397,7 +396,7 @@
 character, and the number of characters in the span.
 This technique was first introduced in [ref ht02 paper].
 
-In Xanadu, characters are written to append-only *scrolls*
+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
 do not actually contain the characters; instead, they are
@@ -415,8 +414,9 @@
    the data is transcluded.
 
 Our current implementation shows only links between documents
-that are in memory at the same time [screenshot of xupdf].
-In the future, we will implement a global index atop of
+that are in memory at the same time [screenshot of xupdf, perhaps ref too
+ (submitted) ?].
+In the future, we will implement a global distributed index at top of
 a distributed hashtable, with the scroll blocks' ids as the keys.
 To find the transclusions of a span, the system will retrieve
 all transclusions of any span in the scroll block, then
@@ -427,8 +427,12 @@
 will be relatively small (limited by the amount of text
 the user enters between two saves of a document), we hope
 that this will not be a major scalability problem. Otherwise,
-systems that allow range queries, such as skip graphs [ref],
-may prove useful.
+systems that allow range queries, such as skip graphs [ref] 
+and skipnet [ref], may prove useful.
+
+[This might be relevant:
+http://www.hpl.hp.com/techreports/2002/HPL-2002-209.pdf
+-Hermanni]
 
 One question raised by xanalogical storage is which links to show
 for a popular document that has been linked to by many users.
@@ -451,6 +455,10 @@
 implementation on top of a distributed hashtable
 will be trivial.
 
+[Benja, this might be useful for defining APIs for DHTs etc: 
+http://sahara.cs.berkeley.edu/jan2003-retreat/ravenben_api_talk.pdf
+Full paper will appear in IPTPS 2003 -Hermanni]
+
 In Storm, applications are not allowed to put arbitrary
 mappings into the index. Instead, applications that want 
 to index blocks provide the following callback
@@ -509,6 +517,8 @@
 are able to scale to the load to store a mapping for each word
 occuring in a document.
 
+[There are two refs about keywords in DHTs-- should we ref these ? -Hermanni]
+
 
 6. Versioning
 =============
@@ -601,7 +611,7 @@
 In summary, the current pointer system seems promising, but 
 there are a number of unresolved issues with it:
 
-- signatures needed online
+- signatures needed online [possible refs: ConChord, SDSI/SPKI ? -Hermanni]
 - multiple 'current' versions annoying
 - not suited to Web-like publishing
 
@@ -747,7 +757,7 @@
 operations (footnote about 'stable state' ?), while broadcasting can't achieve 
 either of these.
 
-[footnote: It's not clear  whether all proposed DHT designs can preserve
+[footnote: It's not clear whether *all* proposed DHT designs can preserve
 (poly)logarithmic properties when participants are heterogeneous and they 
 join and leave the system in a dynamic manner.