[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

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

Modified files:
        storm          : article.rst 

Log message:
        use cases getting there

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.98 manuscripts/storm/article.rst:1.99
--- manuscripts/storm/article.rst:1.98  Wed Feb  5 20:05:56 2003
+++ manuscripts/storm/article.rst       Wed Feb  5 20:29:30 2003
@@ -44,15 +44,14 @@
 computers: being sent as e-mail attachments, carried around on disks,
 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 may be independently modified 
-on two (or more) unconnected, separete systems. We use
-*data mobility* as a collective term for the movement of documents
+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
+.. [#] While the physical mobility of e.g. notebooks may effect
    data mobility (for example due to caching for off-line access), 
-   XXX
+   data mobility is neither the same as, nor limited to the physical
+   movement of devices.
 
 We address two issues raised by data mobility:
 Dangling links and keeping track of alternative versions. 
@@ -60,7 +59,7 @@
 make these issues much easier to deal with, since data
 can be recognized whereever it is moved. 
 
-Dangling links are an issue when documents are moved
+*Dangling links* are an issue when documents are moved
 between servers; when no network connection is available,
 but there is a local copy (e.g. on a laptop or dialup system);
 or when the publisher removes a document permanently,
@@ -69,11 +68,9 @@
 when a document and a link to it are received independently,
 for example as attachments to independent emails,
 or when a link is sent by mail and the document is available
-from the local intranet.
-
-Alternate versions are an issue when [syncing versions by mail/disk,
-central sync point, off-line work on shared repository,
-moving between own systems].
+from the local intranet. When two people meet e.g. on the train,
+they should be able to form an ad-hoc network and follow links
+to documents stored on either one's computer [ref Thompson et al].
 
 Advanced hypermedia systems such as Microcosm and Hyper-G
 address dangling links through a notification system:
@@ -91,6 +88,19 @@
 This would be extremely difficult to realize through a
 notification mechanism like Microcosm's and Hyper-G's.
 
+*Tracking alternative versions* is an issue when documents are modified
+on several independent, unconnected systems, for example 
+when a user takes a document home from work on a floppy disk;
+when they keep the same set of documents on their desktop and laptop,
+modifying them on each; when two people collaborate on a document, 
+sending each other versions of the document by email; 
+when someone downloads a document, modifies it, and publishes
+the modified version (e.g., a manual licensed under the Gnu FDL [ref]),
+or when a group of people collaborate on a set of documents,
+synchronizing irregularly with a central server (as in CVS [ref]),
+a network (as in Lotus Notes [ref]) or with each other 
+(as in Groove[?] [ref]). In each of these cases, a user should be able
+
 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
@@ -109,9 +119,9 @@
 On top of Storm, we have built a system for storing mutable, versioned data
 and an implementation of Xanalogical storage [ref].
 
-XXX {The current implementation has been used for local disk storage
-and central sync point. Our p2p impl is in a very early stage, and
-we have not yet implemented ad-hoc sharing (aka train collaboration).]
+Our current implementation has been used for local disk storage
+and with a central repository. The peer-to-peer functionality
+is in a very early stage and not usable yet.
 
 .. [General figure of Storm, i.e. application layer, storm layer, 
    netowork layer ? -Hermanni]