[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

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

Modified files:
        storm          : article.rst 

Log message:
        little progress after coming back, no time to write during family event 
:-/

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.85 manuscripts/storm/article.rst:1.86
--- manuscripts/storm/article.rst:1.85  Tue Feb  4 09:08:42 2003
+++ manuscripts/storm/article.rst       Wed Feb  5 15:27:59 2003
@@ -45,37 +45,36 @@
 published on the web, moved between desktop and laptop systems,
 downloaded for off-line reading or copied between computers in a LAN. 
 Furthermore, the same document is independently modified 
-on two (or more) unconnected, separete systems. We address two issues
-raised by this ad hoc *data mobility* (see footnote) phenomenon: Dangling 
links, 
-and keeping track of alternative versions. Resolvable location independent 
identifiers
+on two (or more) unconnected, separete systems. We use
+*data mobility* as a collective term for the movement of documents
+between computers (or locations on one computer, such as folders),
+and movement of content between documents (through copy&paste) [#]_.
+
+.. [#] While the physical mobility of e.g. notebooks may introduce
+   data mobility (for example due to caching for off-line access), 
+   XXX
+
+We address two issues raised by data mobility:
+Dangling links and keeping track of alternative versions. 
+Resolvable location independent identifiers
 make these issues much easier to deal with, since data
-can be recognized whereever it is moved. The design also allows for
+can be recognized whereever it is moved. {{The design also allows for
 automatic balancing of the load, which occurs in location-dependent
-situations with popular items.
-
-footnote: we emphasize the mobility of *data*. Indeed, technology used
-for transferring data is not our primary concern. On the other hand, the
-mobility of people is obviously a particular reason for data mobility. 
-For data mobility, the mobility of people shows as the mobility of the
-data processing devices, between/among which the data is shared
-(transferred). XXX Hence, solving issues of data mobility may address e.g.
-problems of mobile hypermedia.
+situations with popular items.}}
 
 In this paper, we present Storm (for *storage module*), a design 
-for dealing with these issues. Storm provides an interface to
-applications for storing and retrieving data in immutable
+dealing with these issues. Storm is a library
+for storing and retrieving data in immutable
 byte sequences identified by cryptographic content hashes
 [ref ht'02 paper], unifying the namespaces of
 private data and documents published on the Internet by
-using the same identifiers for both.
-
-
-The main contributions of this paper are
--Storm - design which employs new techniques for hypermedia 
-systems (location independent identifiers, immutable block storage, *working* 
links etc.)
--use of p2p architecture in hypermedia domain 
+using the same identifiers for both. Storm provides services
+for storing versioned data and Xanalogical storage [ref].
+The Storm design, a hypermedia system built to make use
+of the emerging peer-to-peer search technologies,
+is the main contribution of this paper.
 
-Currently, Storm has been partially implemented as a part of the Gzz 
+Currently, Storm is partially implemented as a part of the Gzz 
 project [ref], which uses Storm exclusively for all disk storage.
 Gzz provides a general platform for building hypermedia applications upon.
 On top of Storm, we have built a system for storing mutable, versioned data
@@ -89,9 +88,10 @@
 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 (other) Open Hypermedia
+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 
@@ -109,6 +109,8 @@
 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