[Gzz-commits] manuscripts/storm article.rst

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Hermanni Hyytiälä <address@hidden>      03/01/31 06:25:08

Modified files:
        storm          : article.rst 

Log message:
        New section order suggestion

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.61 manuscripts/storm/article.rst:1.62
--- manuscripts/storm/article.rst:1.61  Fri Jan 31 05:58:56 2003
+++ manuscripts/storm/article.rst       Fri Jan 31 06:25:07 2003
@@ -19,9 +19,9 @@
 However, recent developments in peer-to-peer systems have
 rendered this assumption obsolete. Distributed hashtables
 [ref chord, can, tapestry, pastry, kademlia, symphony, viceroy]
-and similar systems [skip graph, swan] allow routing based on
-random identifiers on a global scale. This, we believe,
-may be the most important result of peer-to-peer 
+and similar systems [skip graph, swan] allow *location independent* routing 
+based on random identifiers on a global scale. This, we believe,
+may be the most important result of intense peer-to-peer 
 research with regard to hypermedia.
 
 In today's computing world, documents move quite freely between 
@@ -29,9 +29,9 @@
 published on the web, moved between desktop and laptop systems,
 downloaded for off-line reading or copied between computers in a LAN. 
 Often, the same document is independently modified 
-on two unconnected, separete systems. We address two issues
-raised by this *data mobility*: Dangling links, and keeping track
-of alternative versions. Resolvable location-independent identifiers
+on two more more unconnected, separete systems. We address two issues
+raised by this *data mobility* phenomenon: Dangling links, and keeping track
+of alternative versions. Resolvable location independent identifiers
 make these issues much easier to deal with, since data
 can be recognized whereever it is moved.
 
@@ -46,8 +46,12 @@
 which uses Storm exclusively for all disk storage. On top of Storm,
 we have built a system for storing mutable, versioned data
 and an implementation of Xanalogical storage [ref].
+[General figure of Storm, i.e. application layer, storm layer, 
+netowork layer ? -Hermanni]
 
-The main contributions of this paper are 
+The main contributions of this paper are
+-Storm - which employs new techniques (immutable block storage, *working* 
links etc.)
+-use of p2p architecture in hypermedia domain 
 
 This paper is structured as follows. In next section, we describe 
 related work. In section 3, we introduce the basic storage unit of our 
@@ -60,6 +64,16 @@
 potential peer-to-peer implementations of Storm. In section 8, 
 we report on implementation experience and future directions. 
 Section 9 concludes the paper.
+[Suggestion: In next section, we describe 
+related work. In section 3, we give an overview of Storm. In 
+section 4, we discuss the details of basic storage unit. In 
+section 5, we discuss our implementation of Xanalogical storage 
+on top of the block system. In section 6 we discuss application-specific 
+reverse indexing of blocks by their content and techiques for 
+efficient versioned storage of mutable data on top of blocks. In 
+section 7, we discuss potential peer-to-peer implementations of Storm. 
+In section 8, we report on implementation experience and future 
+directions. Section 9 concludes the paper. -Hermanni]
 
 
 2. Related Work