[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/15 11:37:50

Modified files:
        storm          : article.rst 

Log message:
        remove section numbers as latex adds them automatically :-/

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.171 manuscripts/storm/article.rst:1.172
--- manuscripts/storm/article.rst:1.171 Sat Feb 15 11:35:50 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 11:37:50 2003
@@ -25,8 +25,8 @@
 distributed hashtables, DHT
 
 
-1. Introduction
-===============
+Introduction
+============
 
 The Web and many other hypermedia systems assume that identifiers
 either have to include location information (as in regular URLs, which break 
@@ -182,11 +182,11 @@
 Section 8 concludes the paper.
 
 
-2. Related Work
-===============
+Related Work
+============
 
-2.1. Dangling links
--------------------
+Dangling links
+--------------
 
 The dangling link problem has received a lot of attention
 in hypermedia research (e.g. [davis98referential]_). As examples, we examine 
the ways
@@ -243,8 +243,8 @@
 no matter which peer in the network they are stored on.
 
 
-2.2. Alternative versions
--------------------------
+Alternative versions
+--------------------
 
 Version control systems like CVS or RCS [tichy85rcs]_ usually assume
 a central server hosting a repository. The WebDAV/DeltaV protocols,
@@ -274,8 +274,8 @@
    http://citeseer.nj.nec.com/227358.html that are about OHProtocol.
 
 
-2.3. Peer-to-peer systems
--------------------------
+Peer-to-peer systems
+--------------------
 
 During the last few years, there has been a lot of research
 related to peer-to-peer resource discovery, both in academy 
@@ -373,8 +373,8 @@
 in the indexing overlay network.
    
    
-3. Overview of Xanalogical storage
-==================================
+Overview of Xanalogical storage
+===============================
 
 In the xanalogical storage model [ted-xu-tech]_, 
 pioneered by the unfinished Project Xanadu,
@@ -474,8 +474,8 @@
     \end{figure*}
 
 
-4. Storm block storage
-======================
+Storm block storage
+===================
 
 In Storm, all data is stored
 as *blocks*, byte sequences identified by a SHA-1 
@@ -626,8 +626,8 @@
 to overcome the limitations of traditional file-based applications.
 
 
-4.1. Implementation
--------------------
+Implementation
+--------------
 
 Storm blocks are MIME messages [borenstein92mime]_, i.e., objects with
 a header and body as used in Internet mail or HTTP.
@@ -702,8 +702,8 @@
    the software (mutable documents are described in section 6.1).
 
 
-5. Application-specific reverse indexing
-========================================
+Application-specific reverse indexing
+=====================================
 
 Finding links and transclusions in
 Xanalogical storage is only one example of *reverse indexing*
@@ -779,8 +779,8 @@
    through our index system at all... -b
 
 
-6. Versioning
-=============
+Versioning
+==========
 
 We implement mutable documents on top of block storage
 using a combination of two mechanisms.
@@ -789,8 +789,8 @@
 we do not store each version, but only the differences between versions.
 
 
-6.1. Pointers: implementing mutable resources
----------------------------------------------
+Pointers: implementing mutable resources
+----------------------------------------
 
 A Storm pointer is a globally unique identifier (usually created randomly)
 that can refer to different blocks over time. A block a pointer
@@ -882,8 +882,8 @@
 .. authenticating -> [possible refs: ConChord, SDSI/SPKI ? -Hermanni]
 
 
-6.2. Diffs: storing alternative versions efficiently
-----------------------------------------------------
+Diffs: storing alternative versions efficiently
+-----------------------------------------------
 
 .. [Hm, should we move/remove 'Additionally, many versioning'
    paragraph into related work ? -Hermanni]
@@ -1005,16 +1005,16 @@
 would have to be sent through the network.
 
 
-7. Discussion
-=============
+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
---------------
+Evaluation
+----------
 
 To evaluate the design, the issues raised by data mobility are revisited in
 the following. For the two issues addressed, *dangling links* and *tracking
@@ -1079,8 +1079,8 @@
 
 There are, however, several open issues that are discussed next.
 
-7.2 Status, open issues and future work
----------------------------------------
+Status, open issues and future work
+-----------------------------------
 
 .. [worth to mention, security in general ? -Hermanni]
    1) Open issue: We want to be able
@@ -1176,8 +1176,8 @@
 
    
 
-8. Conclusions
-==============
+Conclusions
+===========
 
 We have addressed two important issues raised by data mobility, dangling 
 links and keeping track of alternative versions. Moreover, we have presented 
@@ -1207,8 +1207,8 @@
 on structured overlay networks such as DHTs.
 
 
-9. Acknowledgements
-====================
+Acknowledgements
+================
 
 We would like to thank Erno Kuusela, Sarah Stehlig and
 Harri Oinas-Kukkonen for comments and discussions.