[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/09 03:49:00

Modified files:
        storm          : article.rst 

Log message:
        More; overview diagram, conclusions.

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.120 manuscripts/storm/article.rst:1.121
--- manuscripts/storm/article.rst:1.120 Sun Feb  9 01:52:55 2003
+++ manuscripts/storm/article.rst       Sun Feb  9 03:49:00 2003
@@ -124,8 +124,6 @@
 and versioning, while we use Xanalogical storage
 to address the movement of content between documents (copy&paste).
 
-.. [XXX figure of the different layers in Storm]
-
 The main contribution of this paper is the Storm design, 
 a hypermedia system built to use the emerging 
 peer-to-peer search technologies to enhance data mobility. 
@@ -139,20 +137,6 @@
 providing a platform for hypermedia-aware applications.
 The peer-to-peer functionality is in a very early stage and not 
 usable yet.
- 
-.. [Move somewhere else -b]:
-   [Section 7 ?-) -Hermanni]
-   No work on integrating Storm with current programs (in the spirit of Open 
Hypermedia)
-   has been done so far. It is not clear how far this is possible
-   without changing applications substantially, if advantage
-   of our implementation of Xanalogical storage is to be taken.
-   (Vitali [ref] notes that Xanalogical storage necessiates
-   strong discipline in version tracking, which current systems lack.)
-
-.. Investigating the degrees of interoperability with Open Hypermedia
-   (/Structural Computing?) and (more primitive?) other (Web) XXX is a possible
-   direction for future work, and will be preliminarly discussed here too.
-   [benja says: Really? Do we/can we discuss that really? antont: 'll try.]
 
 This paper is structured as follows. In the next section, we describe 
 related work. In section 3, we introduce the basic storage unit of our 
@@ -165,6 +149,35 @@
 we report on implementation experience and future directions. 
 Section 8 concludes the paper.
 
+.. uml:: storm_layers
+
+    package Blocks
+
+    package Indexing
+        use Blocks
+
+    package XuStorage
+        use Indexing
+        use Blocks
+  
+    package Pointers
+        use Indexing
+        use Blocks
+
+    package Diffs
+        use Indexing
+        use Blocks
+
+    ---
+    Blocks.c = (0,0);
+    vertically(55, foo, Blocks, Indexing);
+
+    dx = 80; dy = 60;
+    XuStorage.c = Indexing.c + (-dx, -dy);
+    z1 = Indexing.c + (dx, -dy);
+    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.]
 
@@ -985,11 +998,11 @@
 the difference from ``A`` to ``C``, and replace the two
 previous differences by it. If we also store a difference
 between version ``C`` and ``D``, it does not need
-to be altered, because it refers to *version ``C``* and not
+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.]
+.. [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
@@ -1001,7 +1014,7 @@
    that can be 'skipped' will have to be much higher
    for this mechanism to be useful.
 
-[XXX fig?]
+.. [XXX fig?]
 
 Our current implementation is a layer above Storm block storage
 and indexing. This layer implements a ``load(version-id) -> version``
@@ -1167,6 +1180,11 @@
 might allow for the (even substantial) changes that 'xanalogicalising' it
 would mean in practise. For Gzz, Zope might provide a window to the Web.
 
+ .. Investigating the degrees of interoperability with Open Hypermedia
+   (/Structural Computing?) and (more primitive?) other (Web) XXX is a possible
+   direction for future work, and will be preliminarly discussed here too.
+   [benja says: Really? Do we/can we discuss that really? antont: 'll try.]
+
 (Also about OHProtocol? will check)
 
 When Xanalogical storage is not applied, using Storm as a
@@ -1192,7 +1210,33 @@
 8. Conclusions
 ==============
 
-XXX
+We have presented the Storm design, which makes use of recent advances
+in peer-to-peer technology to support many different forms
+of data mobility. All data is stored in immutable blocks,
+of which application-specific indices can be kept. On top of
+indexed blocks, we implement efficient versioned storage
+of mutable resources as well as Xanalogical storage.
+
+Storm is not limited to network publishing;
+it is intended to be used for private documents stored on
+desktop systems as well. Our current implementation does not support
+peer-to-peer distribution yet, but the Gzz project has used it 
+for local storage and server-based collaboration
+for one and a half years.
+
+Storm has proven to be a solid basis for Gzz, but
+no work has been done to integrate it with existing systems, yet.
+This makes Storm a rather monolithic approach at present.
+However, even if Storm-- or especially Xanalogical storage--
+should be hard to integrate with existing systems,
+we believe that it is valuable as an exercise in what is possible
+if we can break backwards compatibility with the state of the art.
+
+At the very least, we hope to provide a case study in
+what's possible in a system that does not use
+location-dependent identifiers at all. We hope to raise awareness
+for the prospects of location-independent systems based
+on structured overlay networks like DHTs.
 
 
 9. Acknowledgements