[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

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

Modified files:
        storm          : article.rst 

Log message:
        Summarize antont's use cases

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.91 manuscripts/storm/article.rst:1.92
--- manuscripts/storm/article.rst:1.91  Wed Feb  5 17:05:04 2003
+++ manuscripts/storm/article.rst       Wed Feb  5 17:40:01 2003
@@ -60,6 +60,16 @@
 make these issues much easier to deal with, since data
 can be recognized whereever it is moved. 
 
+Examples for data mobility include:
+
+- train collaboration
+- email attachment synchronization of versions
+- publication, hosting on own computer
+- comments and links on published document
+- travelling with laptop, off-line work
+- load
+- reconnecting the laptop after off-line work
+
 .. The design also allows for
    automatic balancing of the load, which occurs in location-dependent
    situations with popular items. [benja says: This is not related
@@ -74,7 +84,7 @@
 on the public Internet. 
 
 Location-independent identifiers for documents 
-make such a notification unnecessary; a peer-to-peer lookup system 
+make such notification unnecessary; a peer-to-peer lookup system 
 can resolve them whereever the documents are moved.
 Such a system also works for data not publicized on the Internet.
 For example, if one email has a document attached to it, and another email
@@ -83,8 +93,6 @@
 This would be extremely difficult to realize through a
 notification mechanism like Microcosm's and Hyper-G's.
 
-XXX use cases
-
 In this paper, we present Storm (for *storage module*), a design 
 dealing with these issues. Storm is a library
 for storing and retrieving data as immutable
@@ -119,7 +127,7 @@
    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 
+This paper is structured as follows. In the next section, we describe 
 related work. In section 3, we introduce the basic storage unit of our 
 system, file-like blocks of data identified by cryptographic hashes. 
 In section 4, we discuss our implementation of Xanalogical storage