[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/15 12:56:58

Modified files:
        storm          : article.rst 

Log message:
        conclusion better now

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.187 manuscripts/storm/article.rst:1.188
--- manuscripts/storm/article.rst:1.187 Sat Feb 15 12:43:40 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 12:56:58 2003
@@ -1082,21 +1082,19 @@
 raised by data mobility, dangling links and keeping track 
 of alternative versions. In Storm, all data is stored as immutable blocks
 identified a SHA-1 hash. Application-specific indices of these blocks can be 
kept.
-On top of indexed blocks, we have implemented efficient versioned 
+On top of indexed blocks, we have implemented versioned 
 storage of mutable resources as well as Xanalogical storage.
 
 Storm is not limited to network publishing;
-it can be also used for private document repository. Our current 
implementation 
+it can be also used for private document repository. Our present 
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.
-Currently, we are working on completing our GISP-based peer-to-peer
-implementation of Storm. In the future, we intend to explore
-other DHT implementations, too.
+Currently, we are working on a GISP-based peer-to-peer
+implementation.
 
 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 
[vitali99versioning]_
+Hypermedia) has been done yet. This may be difficult with Xanalogical
+storage; Vitali [vitali99versioning]_
 notes that Xanalogical storage necessiates strong discipline in version 
tracking,
 which current systems lack. 
 This makes Storm a rather monolithic approach at present.
@@ -1105,21 +1103,20 @@
 (with features outside the focus of Gzz)
 which implements strict versioning, and to modify it to use Storm for storage. 
 A candidate is the object-oriented Web publishing environment Zope [zope]_, 
-which is Free Software and stores everything by default as diffs to
-a (flat file) database. The
+which is Free Software. The
 open hypermedia protocol (OHP) may be another possibiliy [reich-davis99-ohp].
 
-Besides these issues with the backend, we are facing user interface issues
-as well -- for example the conventions for listing, moving and deleting
-blocks. 
+Work is also needed on user interfaces for Storm.
 
-.. Also conventions for which zones e.g. new blocks should be stored in
+.. Besides these issues with the backend, we are facing user interface issues
+   as well -- for example the conventions for listing, moving and deleting
+   blocks. Also conventions for which zones e.g. new blocks should be stored in
    must be resolved. Often they will be private, but when making changes to
    documents that are shared with a project group, the changes should be
    visible to others.
 
-We have provided a case study in
-what's possible in a system that does not use
+We see Storm as a case study in
+the potentials of 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 such as DHTs.