[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/15 06:34:59

Modified files:
        storm          : article.rst 

Log message:
        twiddles

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.152 manuscripts/storm/article.rst:1.153
--- manuscripts/storm/article.rst:1.152 Sat Feb 15 05:52:18 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 06:34:59 2003
@@ -9,14 +9,15 @@
 movement of documents between computers, different locations 
 on one computer and movement of content between documents.
 We identify dangling links and alternative versions as major
-obstacles for the free movement of data. This paper presents a Storm 
+obstacles for the free movement of data. This paper presents the Storm 
 (STORage Module) design as one possible solution to the problems in 
 the above scenarios. Storm uses location-independent globally unique 
-identifiers, immutable block storage and peer-to-peer networking to 
+identifiers, append-and-delete-only storage and peer-to-peer networking to 
 resolve problems raised by data mobility. Moreover, we discuss some 
 specific use scenarios related to ad hoc networks, unreliable network 
 connections and mobile computing, in which the need for data mobility 
-is obvious. 
+is obvious. Our current prototype implementation works on a single system;
+peer-to-peer networking is in an early prototype stage.
 
 
 Keywords: hypermedia, versioned hypermedia, dangling links, xanalogical 
storage, P2P, 
@@ -45,8 +46,8 @@
 research with regard to hypermedia.
 
 In this paper, we examine how location-independent identifiers can 
-support *data mobility*. Our motivation has been inspired by today's computing 
-world, in which documents move quite freely between computers: they are sent 
as 
+support *data mobility*. Documents often move quite freely 
+between computers: they are 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. We use 'data mobility' as a collective 
@@ -62,7 +63,9 @@
 Dangling links and keeping track of alternative versions. 
 Resolvable location-independent identifiers
 make these issues much easier to deal with, since data
-can be identified wherever it is moved [#]_. 
+can be identified wherever it is moved [#]_.
+Current systems dealing with these issues
+often do not deal well with many data mobility.
 
 .. [#] It might be more appropriate to speak about *resources*
    and *references* instead of *documents* and *links*, but
@@ -111,11 +114,11 @@
 or when a group of people collaborate on a set of documents,
 synchronizing irregularly with a central server (as in CVS [cvs]_),
 a network of servers (as in Lotus Notes) or directly with each other 
-(as in Groove[?] [ref]). In each of these cases, a user should be able
+(as in Groove [groovesurl]_). In each of these cases, a user should be able
 to work on the version at hand and then either merge it with others 
 or fork to a different branch.
 
-In this paper, we present Storm (for *STOrage Module*), a design 
+In this paper, we present Storm (for *STORage Module*), a design 
 dealing with versioning and dangling links. Storm is a library
 for storing and retrieving data as *blocks*, immutable
 byte sequences identified by cryptographic content hashes
@@ -123,29 +126,8 @@
 for versioned data and Xanalogical storage [ted-xanalogical-structure-needed]_.
 We address the mobility of documents by block storage
 and versioning, while we use Xanalogical storage
-to address the movement of content between documents (copy&paste).
-
-The main contribution of this paper is the Storm design, 
-a hypermedia system built to use the emerging 
-peer-to-peer data lookup technologies to enhance data mobility. 
-Additionally, we hope to 
-provide an input to the ongoing discussion about peer-to-peer
-hypermedia systems
-[thompson01coincidence-andalso-bouvin02open-andalso-p2p-hypertext-panel-andalso-lukka02guids]_.
-Currently, Storm is partially implemented as a part of the Gzz 
-project [gzz]_, which uses Storm exclusively for all disk storage.
-Storm's peer-to-peer functionality is in a very early stage and not 
-usable yet.
-
-This paper is structured as follows. In the next section, we describe 
-related work. In section 3, we give an overview of xanalogical model.
-In section 4, we introduce the basic storage unit of our 
-system, i.e. file-like blocks identified by cryptographic hashes. In section 
5, 
-we discuss application-specific 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 report on implementation experience and future directions. 
-Section 8 concludes the paper.
+to address the movement of content between documents (copy&paste);
+see Fig. [ref-storm_layers]_.
 
 .. uml:: storm_layers
     :caption: The Storm model
@@ -177,8 +159,27 @@
     Pointers.c = z1 + (15, 25);
     Diffs.c = z1 - (15, 15);
 
-.. [Use cases in intro, discussion on how Storm applies to them
-   to the end/in Conclusions.]
+The main contribution of this paper is the Storm design, 
+a hypermedia system built to use the emerging 
+peer-to-peer data lookup technologies to enhance data mobility. 
+Additionally, we hope to 
+provide an input to the ongoing discussion about peer-to-peer
+hypermedia systems
+[thompson01coincidence-andalso-bouvin02open-andalso-p2p-hypertext-panel-andalso-lukka02guids]_.
+Currently, Storm is partially implemented as a part of the Gzz 
+project [gzz]_, which uses Storm exclusively for all disk storage.
+Storm's peer-to-peer functionality is in a very early stage and not 
+usable yet.
+
+This paper is structured as follows. In the next section, we describe 
+related work. In section 3, we give an overview of xanalogical model.
+In section 4, we introduce the basic storage unit of our 
+system, i.e. file-like blocks identified by cryptographic hashes. In section 
5, 
+we discuss application-specific 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 report on implementation experience and future directions. 
+Section 8 concludes the paper.
 
 
 2. Related Work
@@ -246,7 +247,8 @@
 Version control systems like CVS or RCS [tichy85rcs]_ usually assume
 a central server hosting a repository. The WebDAV/DeltaV protocols,
 designed for interoperability between version control systems, inherit
-this assumption [rfc2518-andalso-rfc3253]_. On the other hand, Arch [arch]_ 
places all repositories
+this assumption [rfc2518-andalso-rfc3253]_. 
+On the other hand, Arch [arch]_ places all repositories
 into a global namespace and allows independent developers 
 to branch and merge overlapping repositories without any central control
 [is there a specific ref for this?].
@@ -399,7 +401,7 @@
 
 In the end, some peers will necessarily be more equal than others:
 Published data will be hosted on servers
-which are permanently on-line, but act as ordinary peers
+which are permanently on-line, but are otherwise ordinary peers
 in the indexing overlay network.
    
    
@@ -407,7 +409,7 @@
 ==================================
 
 In the xanalogical storage model [ted-xu-tech]_, 
-pioneered by the unfinished Project Xanadu [ted-xu-tech]_,
+pioneered by the unfinished Project Xanadu,
 links are not between documents, but individual characters.
 When a character is first typed in, it acquires a permanent id
 ("the character 'D' typed by Janne Kujala on 10/8/97 8:37:18"),
@@ -497,7 +499,7 @@
 may be beneficial for the members of the group to see other members'
 comments of articles etc.
 
-Figure XYZ illustrates how xanalogical storage addresses the issue of
+Figure [ref-figdocmovement]_ illustrates how xanalogical storage addresses the 
issue of
 movement of data between documents. Initially, there are documents D1 and
 D2, with two links (directed arrows in the figure) from D1 to two different
 elements in D2, A and B. The links actually are to the /spans/ A and B that
@@ -1036,9 +1038,6 @@
 to be altered, because it refers to *version* ``C`` and not
 the difference to ``C`` from ``B`` (as in the simplistic scheme).
 
-.. [XXX Figure: diffs from a->b, b->c, c->d; we replace
-   the diffs a->b and b->c by a single diff a->c.]
-
 We can also store the block containing version ``D``
 in addition to storing the versions above. Then, we can reconstruct
 version ``C`` in two ways: By using the diffs from ``A`` to ``B``
@@ -1049,8 +1048,6 @@
    that can be 'skipped' will have to be much higher
    for this mechanism to be useful.
 
-.. [XXX fig?]
-
 Our current implementation is a layer above Storm block storage
 and indexing. This layer implements a ``load(version-id) -> version``
 interface through the following simplified algorithm:
@@ -1123,11 +1120,13 @@
 
 
 7. Discussion
-===================================
+=============
+
 In this section we evaluate Storm's design with regard to previously presented
 use cases, summarize Storm's implementation status and outline open issues
 and future work.
 
+
 7.1 Evaluation
 --------------
 
@@ -1142,20 +1141,20 @@
 id returns a location where the data is currently available. If the
 publisher removes the document permanently, but it is archived elsewhere,
 the archives act as peers similarly. When there is no network connection
-available, but a local copy instead, the lookup points to that. If a
+available, but a local copy instead, Storm can find it. If a
 document and a link to it are received independently, e.g. as attachments in 
 separate e-mails, or a link to a document in the local intranet is e-mailed, 
-(all those links work :o .. this was also discussed in intro already (index))
 When people meet live, e.g. on a train, and form an ad-hoc network, they are
-able to see each other's documents and follow links to them if a
-peer-to-peer implementation of Storm is used (and pools published
-accordingly..? what should be discussed here?).
+able to see each other's public documents and follow links to them if a
+peer-to-peer implementation of Storm is used.
 Finally, if a document is split to parts (or content from one copy-pasted to
 another), links to the elements that are then in the new documents do not
 break, bacause with xanalogical storage the links are actually to spans that
 are transcluded in all the documents that show them (as illustrated in
-figure XYZ in section 3, xanalogical storage).
+figure [ref-figdocmovement]_ in section 3).
  
+.. (all those links work :o .. this was also discussed in intro already 
(index))
+
 *Tracking alternative versions*. Because Storm utilises immutable blocks,
 each modification to a document creates a new block. When a document is
 modified on several independent, unconnected systems, if there are
@@ -1186,7 +1185,6 @@
 
 7.2 Status, open issues and future work
 ---------------------------------------
-
 
 [worth to mention, security in general ? -Hermanni]
 1) Open issue: We want to be able