[Gzz-commits] manuscripts/storm article.rst

[Hermanni Hyytiälä]

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

Modified files:
        storm          : article.rst 

Log message:
        Polish, Open issus: Firewalls/NATs ?

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.101 manuscripts/storm/article.rst:1.102
--- manuscripts/storm/article.rst:1.101 Wed Feb  5 20:53:27 2003
+++ manuscripts/storm/article.rst       Thu Feb  6 03:03:34 2003
@@ -8,12 +8,12 @@
 Problems of data mobility, such as broken links, are identified.
 Motivations and potential solutions are reviewed, and a design for 
 a system being developed for (these purposes) is presented. 
-The design and a partial implementation if it are evaluated 
-in light of use cases from a realistic(?) scenario. Open issues are discussed, 
and the areas for
-future work in areas such as interoperability, scalability and security is
-identified.
+The design and a partial implementation of it is evaluated 
+in light of use cases from a realistic(?) scenarios. Open issues are 
+discussed, and the areas for future work in areas such as 
+interoperability, scalability and security is identified.
 
-Keywords: hypermedia, P2P, location-independent identifiers,
+Keywords: hypermedia, P2P, peer-to-peer, location-independent identifiers,
 versioned hypermedia, xanalogical storage, distributed hashtables
 
 
@@ -76,7 +76,7 @@
 
 Location-independent identifiers for documents 
 make such notification unnecessary; a peer-to-peer lookup system 
-can resolve them whereever the documents are moved.
+can resolve documents whereever 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
@@ -94,16 +94,15 @@
 the modified version (e.g., a manual licensed under the Gnu FDL [ref]),
 or when a group of people collaborate on a set of documents,
 synchronizing irregularly with a central server (as in CVS [ref]),
-a network (as in Lotus Notes [ref]) or with each other 
+a network (as in Lotus Notes [ref]) or directly with each other 
 (as in Groove[?] [ref]). In each of these cases, a user should be able
 
 In this paper, we present Storm (for *storage module*), a design 
 dealing with these issues. Storm is a library
 for storing and retrieving data as *blocks*, immutable
 byte sequences identified by cryptographic content hashes
-[ref ht'02 paper]. Storm provides services
-for versioned data and Xanalogical storage [ref],
-built on top of blocks.
+[ref ht'02 paper]. Additionally, Storm provides services
+for versioned data and Xanalogical storage [ref].
 The Storm design, a hypermedia system built to make use
 of the emerging peer-to-peer search technologies,
 is the main contribution of this paper.
@@ -112,13 +111,14 @@
 project [ref], which uses Storm exclusively for all disk storage.
 Gzz is an implementation of Ted Nelson's zzstructure [ref],
 providing a platform for hypermedia-aware applications.
-The peer-to-peer functionality
-is in a very early stage and not usable yet.
+The peer-to-peer functionality is in a very early stage and not 
+usable yet.
 
 .. [General figure of Storm, i.e. application layer, storm layer, 
    netowork layer ? -Hermanni]
  
 .. [Move somewhere else -b]:
+   [Section 8 ?-) -Hermanni]
    No work on integrating Storm with current programs (in the spirit of Open 
Hypermedia)
    has been done so far. It is not clear how far this is possible
    without changing applications substantially, if advantage
@@ -166,11 +166,15 @@
 from any system storing a copy; this means that documents may be
 accessible even after the original publisher has taken them off-line [#]_.
 
+[Relocate this, e.g. at the end of this section ? -Hermanni]
+
 .. [#] Intentionally or unintentionally. We believe that it is 
    a good thing if published documents remain available even when
    the original publisher wants to retract them; however, discussion
    of the ethical implications of this is outside the scope of this paper.
    (But see [XXX search for refs! ;-)])
+   [Possible refs: http://www.openp2p.com/topics/p2p/p2p_law/.
+   However, they are necessarily directly related to this :( -Hermanni]
 
 Microcosm addressed the linking problems of large archives 
 by separating the links from the documents and storing them on dedicated 
@@ -201,24 +205,25 @@
 
 Even Xanadu [ref], which went a long way to ensure that links do not break
 when their targets are copied from one document to another,
-required permanent connection to a network of servers to function,
-and, at least in its 1988 incarnation [ref Green] addressed data 
+required permanent connection to a network of servers to function. 
+Moreover, Xananu's 1988 incarnation [ref Green] addressed data 
 based on the address of a server holding a 'master copy.'
 
 Lotus Notes [ref], popular database sharing and colloboration tool, has some 
 similarities to Storm. In both systems, for instance, data is identified by 
 using GUIDs. However, partly because of the long age of the system, Lotus 
Notes 
-is limited to client-server architecture, where as Storm exploits peer-to-peer 
+is limited to client-server architecture, where as Storm exploits adaptive 
peer-to-peer 
 architecture. Groove [ref] is a improved design of Lotus Notes, which employs 
-strong security mechanisms and uses peer-to-peer as basis of communication 
-channel among participants. Neither of these systems don't support the 
immutable
-of data.
-
-CFS [ref], which is built upon Chord DHT routing layer[ref], store data as 
blocks. 
-However, CFS *splits* files into several miniblocks and spreads blocks over 
the 
-available CFS servers. Freenet [ref] and PAST [ref, pastry ref] doesn't split 
-files into blocks, since they store data as whole files. All previously 
mentioned 
-systems lack of the immutable property which is used in Storm blocks.
+strong security mechanisms and uses peer-to-peer functionality 
+as basis of communication channel among limited amount of participants. 
+Neither of these systems don't support the immutable of data.
+
+CFS [ref], which is built upon Chord DHT peer-to-peer routing layer[ref], 
stores 
+data as blocks. However, CFS *splits* data (files) into several miniblocks and 
+spreads blocks over the available CFS servers. Freenet [ref] and PAST [ref],
+which is based on Pastry [ref], do not split files into blocks, since they 
store data 
+as whole files. All previously mentioned systems lack of the immutable 
+property which is used in Storm blocks.
    
 Related work: we need something about p2p hypermedia: 
 [ref Bouvin, Wiil ("Peer-to-Peer Hypertext")]
@@ -887,7 +892,9 @@
 
 Open issue/Future directions: implement multisource downloading
 
-Future directions: Implement home node model or directory model ? 
+Future directions: Implement home node model or directory model ?
+
+Open issue: Firewall Transparency/NATs ? 
 
 9. Conclusions
 ==============