[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

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

Modified files:
        storm          : article.rst 

Log message:
        more

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.119 manuscripts/storm/article.rst:1.120
--- manuscripts/storm/article.rst:1.119 Sun Feb  9 01:18:23 2003
+++ manuscripts/storm/article.rst       Sun Feb  9 01:52:55 2003
@@ -141,7 +141,7 @@
 usable yet.
  
 .. [Move somewhere else -b]:
-   [Section 8 ?-) -Hermanni]
+   [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
@@ -161,10 +161,9 @@
 on top of the block system. 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 discuss 
-potential peer-to-peer implementations of Storm. In section 8, 
+of mutable data on top of blocks. In section 7, 
 we report on implementation experience and future directions. 
-Section 9 concludes the paper.
+Section 8 concludes the paper.
 
 .. [Use cases in intro, discussion on how Storm applies to them
    to the end/in Conclusions.]
@@ -498,10 +497,30 @@
 a good or a bad property we leave for the reader to judge.
 
 Finally, because blocks are easy to move from system
-to system, block storage may be more *durable* than files:
+to system, we hope that block storage may be more *durable* than files.
+When users own multiple systems, or buy new systems
+to replace old ones, files are often on one harddisk
+and not the other, or moved to an old floppy disk but not back
+to the harddisk. How many files you created in the 80s
+do you still keep around on your harddisk today? With block storage,
+each time you buy a new computer, it would be possible
+to transfer all blocks from your existing systems to the new one,
+and if you left some lying around on a floppy, you would be able
+to copy it to your harddisk without thinking about issues
+like which directory to keep it in. By making it easy to collect
+blocks produced on a diverse number of systems, it would be easier
+to actually keep that old data around.
+
+Of course, to meet this goal it is necessary that the block
+system remains backwards compatible at all times. We have therefore
+decided to enter a *persistency commitment* when we finalize
+the Storm design before the next release of Gzz: Any future version
+of the Storm specification thereafter will be able
+to handle any block created according to this version of the spec.
+This means that no matter how much we'll regret our current choices
+in the future, we commit to providing backward compatibility for them.
 
-
-These advantages are bought by an utter incompatibility with
+The advantages we have outlined are bought by an utter incompatibility with
 the dominant paradigms of file names and URLs. We hope that
 it would be possible to port existing applications to use Storm
 without too much effort, but we have not investigated
@@ -999,28 +1018,34 @@
 As computing differences is file-format dependent, so is our system
 for storing versions. In our implementation, applications need to
 provide a callback interface for reading and writing versions
-and computing and applying differences. ::
+and computing and applying differences.
+
+.. uml:: version_interfaces
+
+    class Version "interface"
+        methods
+            getDiffFrom(:Version): Diff
+
+    class Diff "interface"
+        methods
+            applyTo(:Version): Version
+            inverse(): Diff
+
+    class VersionFormat "interface"
+        methods
+            readVersion(:InputStream): Version
+            readDiff(:InputStream): Diff        
+
+            writeVersion(:OutputStream, :Version)
+            writeDiff(:OutputStream, :Diff)
+
+    ---
+    Version.c = (100,0);
+    Diff.c = (250, 0);
+    VersionFormat.c = (175, -80);
+    %horizontally(100, foo, Version, Diff);
+    %vertically(120, bar, foo, VersionFormat);
 
-    +--------------------+      +--------------------+
-    | <<interface>>      |      | <<interface>>      |
-    | Version            |      | Diff               |
-    +====================+      +====================+
-    | getDifferenceFrom  |      | applyTo(:Version): |
-    |   (:Version): Diff |      |   Version          |
-    +--------------------+      |                    |
-                                | inverse(): Diff    |
-                                +--------------------+
-
-        +---------------------------------------+
-        | <<interface>>                                |
-        | VersionFormat                                |
-        +=======================================+
-        | readVersion(:InputStream): Version    |
-        | readDiff(:InputStream): Diff         |
-        |                                       |
-        | writeVersion(:OutputStream, :Version) |
-        | writeDiff(:OutputStream, :Diff)       |
-        +---------------------------------------+
 
 The diff system is more complicated than simple block storage,
 and therefore more liable to bugs. Yet, as long as we do not
@@ -1048,14 +1073,7 @@
 would have to be sent through the network.
 
 
-7. Peer-to-peer implementations
-===============================
-
-XXX remove this section: p2p should be discussed in the
-relevant sections above (2-6).
-
-
-8. Experience and future directions
+7. Experience and future directions
 ===================================
 
 Review of the use cases: what does storm in each? --
@@ -1171,13 +1189,13 @@
    the location through the DHT? This might be related to p2p publishing.
 
 
-9. Conclusions
+8. Conclusions
 ==============
 
 XXX
 
 
-10. Acknowledgements
+9. Acknowledgements
 ====================
 
 We would like to thank Sarah Stehlig for discussions.