[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/01/31 01:57:16

Modified files:
        storm          : article.rst 

Log message:
        twid

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.59 manuscripts/storm/article.rst:1.60
--- manuscripts/storm/article.rst:1.59  Thu Jan 30 10:24:25 2003
+++ manuscripts/storm/article.rst       Fri Jan 31 01:57:16 2003
@@ -1,54 +1,60 @@
-========================================================================
-Don't fence me in: Supporting data mobility through the Gzz/Storm design
-========================================================================
+============================================================================
+Gzz Storm: Supporting data mobility through location independent identifiers
+============================================================================
 
 (an-other way (too buzzwordy? but generalized!): enabling distributed
 mobile hypermedia with location independent unique document identifiers)
+['distributed mobile hypermedia' is too limited --b.]
 
 1. Introduction
 ===============
 
-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. 
+The Web and many other hypermedia systems assume that identifiers
+either have to include location information (as in URLs, which break 
+when documents are moved), or can only be resolved locally (as in
+link services that can only find links stored on a select set
+of link servers [ref Microcosm, DLS, ...]). Berners-Lee [ref NameMyth] argues 
that 
+unique random identifiers are not globally feasible for this reason.
+
+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 
+research with regard to hypermedia.
 
-However, in today's computing world, documents move quite freely between 
+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.
-
-The main contributions of this paper are...
+on two unconnected systems. In this paper, we address two issues
+raised by this *data mobility*: 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.
+
+In this paper, we present Storm (for *storage module*), a design 
+for dealing with these issues. Storm provides an interface to
+applications for storing and retrieving data in immutable
+byte sequences identified by cryptographic content hashes
+[ref ht'02 paper], unifying the namespaces of
+private data and documents published on the Internet by
+using the same identifiers for both.
+Storm has been partially implemented as a part of the Gzz project [ref], 
+which uses it 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].
 
+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.
+reverse indexing of blocks by their content, essential for many 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, 
@@ -213,7 +219,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 5).
+(see Section 6).
 
 hemppah: Or should these lines be inserted to some other section and tell more 
about these
 systems, e.g. 5.2 ?
@@ -267,7 +273,7 @@
 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 6, below.
+We discuss peer-to-peer implementations in Section 7, below.
 
 The immutability of blocks should make caching trivial, since it is
 never necessary to check for new versions of blocks.
@@ -296,13 +302,13 @@
 are completely independent of location; when data is moved
 between servers, references to it do not break. (Of course, this
 requires that the blocks can be found no matter what server
-they are on. Again, see Section 6.)
+they are on. Again, see Section 7.)
 
 
 4. Xanalogical storage
 ======================
 
-XXX
+Xanalogical storage, pioneered by Project Xanadu [ref],
 
 
 5. Indexing
@@ -337,8 +343,10 @@
 -------------
 
 In Storm, *pointers* are used to implement mutable resources.
-A pointer is an abstract reference that can point to different
-blocks over time.
+A pointer is a globally unique identifier that can refer to
+different blocks over time.
+
+To assign targets to pointers, a special type of block
 
 ...