[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/02/05 16:43:32

Modified files:
        storm          : article.rst 

Log message:
        put comments into comments :), fix syntax

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.88 manuscripts/storm/article.rst:1.89
--- manuscripts/storm/article.rst:1.88  Wed Feb  5 16:32:17 2003
+++ manuscripts/storm/article.rst       Wed Feb  5 16:43:32 2003
@@ -113,8 +113,9 @@
 Gzz provides a general platform for building hypermedia applications upon.
 On top of Storm, we have built a system for storing mutable, versioned data
 and an implementation of Xanalogical storage [ref].
-[General figure of Storm, i.e. application layer, storm layer, 
-netowork layer ? -Hermanni]
+
+.. [General figure of Storm, i.e. application layer, storm layer, 
+   netowork layer ? -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
@@ -122,10 +123,11 @@
 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?]
+
+.. 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?]
 
 This paper is structured as follows. In next section, we describe 
 related work. In section 3, we introduce the basic storage unit of our 
@@ -139,12 +141,12 @@
 we report on implementation experience and future directions. 
 Section 9 concludes the paper.
 
-(where and how use cases? are not mentioned in either of the above, but are
-currently split in two - hinting somewhere in the beginning and reviewing at
-the and).
-[In appendix A ? -Hermanni]
-[IMHO: Use cases in intro, discussion on how Storm applies to them
-to the end/in Conclusions. -b]
+.. (where and how use cases? are not mentioned in either of the above, but are
+   currently split in two - hinting somewhere in the beginning and reviewing at
+   the and).
+   [In appendix A ? -Hermanni]
+   [IMHO: Use cases in intro, discussion on how Storm applies to them
+   to the end/in Conclusions. -b]
 
 
 2. Related Work
@@ -438,7 +440,7 @@
 
 Our current implementation shows only links between documents
 that are in memory at the same time [screenshot of xupdf, perhaps ref too
- (submitted) ?].
+(submitted) ?].
 In the future, we will implement a global distributed index at top of
 a distributed hashtable, with the scroll blocks' ids as the keys.
 To find the transclusions of a span, the system will retrieve
@@ -487,9 +489,9 @@
 to index blocks provide the following callback
 to a Storm pool::
 
-[What is mapping ? We should explain this :) -Hermanni]
-
     getMappings(block) -> set of (key, value) pairs
+
+.. [What is mapping ? We should explain this :) -Hermanni]
 
 This callback processes a block and returns a set of mappings
 to be placed into the index. The Storm pool, in turn, provides