[Gzz-commits] manuscripts/storm article.rst

[Hermanni Hyytiälä]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Hermanni Hyytiälä <address@hidden>      03/01/29 05:40:48

Modified files:
        storm          : article.rst 

Log message:
        Intro: reorganise. Added related work. Some future directions/open 
issues

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.55 manuscripts/storm/article.rst:1.56
--- manuscripts/storm/article.rst:1.55  Wed Jan 29 05:24:07 2003
+++ manuscripts/storm/article.rst       Wed Jan 29 05:40:47 2003
@@ -11,23 +11,54 @@
 An important assumption underlying the Web and many other hypermedia
 systems is that an identifier, if it is to be resolvable, must
 include information about where to find the resource it identifies.
+On the Web, for instance, documents are tightly bound to one location: they 
+cannot be moved to a different server without breaking links to them[#]_. 
+It is the norm for hypermedia systems to bind documents to hosts, much 
+like the Web.
+
 Berners-Lee [ref NameMyth] argues that identifying documents
 by unique, completely random identifiers may be desirable,
 as unlike for a URL, there is little reason for a random identifier
 ever to be changed, but that it is not possible to resolve such names 
-on a global scale. However, recent development in peer-to-peer systems
-has made scalable indexing systems possible, rendering this assumption
-obsolete [refs: chord, can, tapestry, pastry, kademlia, symphony, viceroy]. 
-This, we believe, is the most important result of peer-to-peer research with 
-regard to hypermedia.
+on a global scale. 
+
+However, in today's computing world, documents move quite freely between 
+computers, being sent as e-mail attachments, carried around on disks,
+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 will be independently modified 
+on two unconnected systems. 
+
+Recent development in peer-to-peer systems has made scalable 
+*location-independent* indexing systems possible, rendering direct 
+identifier-to-location assumption obsolete (emphasize 'location-independent 
routing'!) 
+[refs: chord, can, tapestry, pastry, kademlia, symphony, viceroy, skip graph, 
swan].
+This, we believe, is the most important result of peer-to-peer 
+research with regard to hypermedia.
 
 In this paper, we present Storm, a design for dealing with
 dangling links and keeping track of alternative versions,
 taking advantage of these new developments.
 
-On the Web, documents are tightly bound to one location: they cannot be
-moved to a different server without breaking links to them[#]_. It is the
-norm for hypermedia systems to bind documents to hosts, much like the Web.
+The main contributions of this paper are...
+
+
+This paper is structured as follows. In next section, we describe 
+related work. In section 3, we introduce the basic storage unit of our 
+system, file-like blocks of data identified by cryptographic hashes. 
+In section 4, we discuss our implementation of Xanalogical storage 
+on top of the block system. In section 5, we discuss application-specific 
+reverse indexing of blocks by their content, essential for most applications.
+In section 6, we present 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.
+
+
+2. Related Work
+===============
+...
 However, in advanced hypermedia systems such as Microcosm[] and Hyper-G[],
 several approaches to dealing with the dangling link and other link
 management problems have been developed. Microcosm addressed the linking
@@ -61,12 +92,7 @@
 and, at least in its 1988 incarnation [ref Green] addressed data 
 based on the address of a server holding a 'master copy.'
 
-However, in today's computing world, documents move quite freely between 
computers, being 
-sent as e-mail attachments, carried around on disks,
-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 will be independently modified 
-on two unconnected systems. 
+
 
 
 
@@ -146,23 +172,10 @@
 and keeping track of alternative versions [refs stating problem].
 
 
-The main contributions of this paper are...
 
-->
-This paper is structured as follows. In section 2, we introduce
-the basic storage unit of our system, file-like blocks of data 
-identified by cryptographic hashes. In section 3, we discuss 
-our implementation of Xanalogical storage on top of the block system. 
-In section 4, we discuss application-specific reverse indexing 
-of blocks by their content, essential for most applications.
-In section 5, we present techiques for efficient versioned storage
-of mutable data on top of blocks. In section 6, we discuss 
-potential peer-to-peer implementations of Storm. In section 7, 
-we report on implementation experience and future directions. 
-Section 8 concludes the paper.
 
 
-2. Block storage
+3. Block storage
 ================
 
 In our system, Storm (for *storage module*), all data is stored
@@ -257,19 +270,19 @@
 they are on. Again, see Section 6.)
 
 
-3. Xanalogical storage
+4. Xanalogical storage
 ======================
 
 XXX
 
 
-4. Indexing
+5. Indexing
 ===========
 
 XXX
 
 
-5. Versioning
+6. Versioning
 =============
 
 Clearly, for block storage to be useful, there has to be a way to
@@ -291,7 +304,7 @@
 the cryptographic hash in the full version's block id.
 
 
-5.1. Pointers
+6.1. Pointers
 -------------
 
 In Storm, *pointers* are used to implement mutable resources.
@@ -307,16 +320,16 @@
 as the system matures.
 
 
-5.2. Diffs
+6.2. Diffs
 ----------
 
 XXX
 
 
-6. Peer-to-peer implementations
+7. Peer-to-peer implementations
 ===============================
 
-6.1. Overview
+7.1. Overview
 -------------
 During the last few years, there have been a lot of research efforts related 
 to Peer-to-Peer (p2p) resource discovery, both in industry and academic world.
@@ -355,7 +368,7 @@
 *structural level* of overlay network, i.e. super peers and peer clusters.
 
 
-7. Experience and future directions
+8. Experience and future directions
 ===================================
 
 Open issue: Tree hashing, also possibly needed for (OceanStore-like?)
@@ -364,9 +377,13 @@
 Open issue: We want to be able
 to copy the blocks from the NYT publication pool to our local computer
 and verify offline that it really comes from NYT. How to do this will go
-into the article as an open research question ;-) 
+into the article as an open research question ;-)
+
+Future directions: of course, we shoul implement a prototype
+
+Open issue/Future directions: implement multisource downloading 
 
-8. Conclusions
+9. Conclusions
 ==============
 
 XXX