[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

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

Modified files:
        storm          : article.rst 

Log message:
        restructure

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.177 manuscripts/storm/article.rst:1.178
--- manuscripts/storm/article.rst:1.177 Sat Feb 15 12:11:35 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 12:13:58 2003
@@ -1008,16 +1008,8 @@
 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.
-
-
-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
+To evaluate the design, we revisit the issues raised by data mobility. 
+For the two issues addressed, *dangling links* and *tracking
 alternative versions*, each individual (use) case that was identified in the
 introduction is dealt with here to illustrate Storm.
 
@@ -1075,77 +1067,6 @@
 of replication and caching combined with location-independent identifiers
 enable several improvements, including the possibility to keep on working on
 shared documents even when there is no or an unreliable network connection.
-
-Future work
------------
-
-Currently, we are working on completing our GISP-based peer-to-peer
-implementation of Storm. Once this is done, we intend to explore
-alternative DHT implementations as well. We will also evaluate
-using Merkle hash trees [XXXref] to identify blocks; this would
-allow us to download parts of a block from multiple sources
-simultaneously (as in e.g. [XXX ref Overnet]).
-
-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]_
-notes that Xanalogical storage necessiates strong discipline in version 
tracking,
-which current systems lack. One possibility is to take an existing system
-(with features outside the focus of Gzz)
-that implements strict versioning, and to modify it to use Storm for storage. 
-A candidate is the object-oriented (web) publishing environment Zope [ref 
zope.org/com, book,
-article?], which is Free Software and stores everything by default as diffs to
-a (flat file) database. Another way is studying the applicability of the 
-open hypermedia protocol (OHP) [reich-davis99-ohp].
-
-As mentioned in the presentation of Storm block storage (section 4),
-although the terminology used here is about characters and text, all media
-are considered. There dealing with e.g. video data, with very large file
-sizes, as (collections of) blocks, is partly unresolved.
-
-Besides these issues with the backend, we are facing user interface issues
-as well -- for example the conventions for listing, moving and deleting
-blocks.
-
-.. [not worth to mention ? -Hermanni]
-   [how does video work here, i.e. are they huge blocks or collections of many
-   small, frames? or a sequence between two keyframes?]
-
-   Benja says: Probably large, but the number of links to them 
-   still won't be that big, I guess. Not sure how to discuss this
-   in the text; feel free to propose something :-)
-
-   Toni: will try.. wondering also about who to consult :o
-
-.. [not worth to mention ? -Hermanni]
-   Future directions: Implement home node model or directory model ?
-
-.. [not worth to mention ? -Hermanni]
-   Open issue: Firewall Transparency/NATs ?
-
-.. [not worth to mention, see above ? -Hermanni]
-   Open issue: other related systems (within gzz?) for e.g. more synchronous
-   collabaration (irc?)?
-
-.. [not worth to mention, first p2p proto then these ;) ? -Hermanni]
-   p2p -> cf half-life of peers (Mojo Nation): Is it desirable that 'weak' 
peers
-   participate in a DHT? -- In Circle, peers must have been online
-   for at least an hour... In which ways, then, can 'weak' peers contribute
-   to the network in a p2p fashion? Caching is certainly one central
-   way, esp. when combined with multisource downloading (this can
-   potentially boost download speeds to the full available bandwidth).
-   This is a performance/reliability issue rather than something
-   changing the fundamental qualities of the network, but still important.
- 
-.. [not worth to mention ? -Hermanni]  
-   [Symphony supports heterogeneity of peers -Hermanni]
-
-.. [not worth to mention ? -Hermanni]
-=======
->>>>>>> 1.173
-   The important point about p2p publishing is that no account and setup
-   is necessary to start publishing.
    
 
 Conclusions
@@ -1164,6 +1085,13 @@
 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. Once this is done, we intend to explore
+alternative DHT implementations as well. We will also evaluate
+using Merkle hash trees [XXXref] to identify blocks; this would
+allow us to download parts of a block from multiple sources
+simultaneously (as in e.g. [XXX ref Overnet]).
+
 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.
@@ -1171,6 +1099,19 @@
 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.
+
+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]_
+notes that Xanalogical storage necessiates strong discipline in version 
tracking,
+which current systems lack. One possibility is to take an existing system
+(with features outside the focus of Gzz)
+that implements strict versioning, and to modify it to use Storm for storage. 
+A candidate is the object-oriented (web) publishing environment Zope [ref 
zope.org/com, book,
+article?], which is Free Software and stores everything by default as diffs to
+a (flat file) database. Another way is studying the applicability of the 
+open hypermedia protocol (OHP) [reich-davis99-ohp].
 
 At the end, we hope that we have provided a case study in
 what's possible in a system that does not use