[Gzz-commits] manuscripts/storm article.rst

[Toni Alatalo]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Toni Alatalo <address@hidden>   03/02/12 07:39:34

Modified files:
        storm          : article.rst 

Log message:
        went through the 'use cases', some open points yet and the whole 
treatment questionable. still unsure where to put this

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.132 manuscripts/storm/article.rst:1.133
--- manuscripts/storm/article.rst:1.132 Wed Feb 12 07:35:18 2003
+++ manuscripts/storm/article.rst       Wed Feb 12 07:39:34 2003
@@ -1120,20 +1120,13 @@
 7. Experience and future directions
 ===================================
 
-Review of the use cases: what does storm in each? --
-[ MOVE TO EARLIER PART, SEE ABSTRACT ]
-
-(where&how to put this, if use cases are used like this at all? 
-agreed with benja on irc that we might try this approach - hinting about the
-use cases early on and taking a detailed look later, in light of the design.)
-
 evaluation
 ----------
 
 To evaluate the design, the issues raised by data mobility are revisited in
 the following. For the two issues addressed, *danglink links* and *tracking
 alternative versions*, each individual (use) case that was identified in the
-introduction is used here to illustrate Storm.
+introduction is dealt with here to illustrate Storm.
 
 *Dangling links*. When documents are moved between servers, when using Storm
 the links to them are not affected as the identifiers are
@@ -1141,43 +1134,37 @@
 id returns a location where the data is currently available. If the
 publisher removes the document permanently, but it is archived elsewhere,
 the archives act as peers similarly. When there is no network connection
-available, but a local copy instead, the lookup points to that.
-
-1. live meeting:
-Documents have been assigned block-ids (and urns?) at creation.
-Pools that are shared / set visible for the other user show over the
-network. (...)
-
-2. syncing via a remote connection after working separately:
-Both new versions are actually diffs to the original. Merging is
-application-specific.
-
-3. publising on/from the laptop: 
-B sets the document public (how that is done depends on UI implementation),
-i.e. putting in a published pool, which may reside locally or externally
-e.g. on a (dedicated) server that is "always-on". These public/private zones
-are an area where future research is needed, possibly related to rights and
-permissions etc. too.
-
-4. A and other people viewing, commenting, bookmarking, linking:
-When someone views the document, the system retrieves the datablock.
-Comments may be new entities(?) linking to it, editing would create a new
-version as a diff as a new datablock with a new guid. Bookmarks and links to
-the original are made to the ID of the original, with no trace of the
-location (originally B's laptop). (more info about pointers here, and in the
-next one?)
-
-5. When B takes her laptop off-line, the searches for the ID of her (and
-A's) Document simply result pointing at the other copies (e.g. on A's
-machine).
-
-6. Increasing traffic: The peer-to-peer network can automatically share the
-load, as popular items get replicated and further delivered from different
-hosts. (does storm actually do this / is it aimed at this?)
-
-7. When B reconnects, can check comments to the Document etc? How does that
-happen? Index?
+available, but a local copy instead, the lookup points to that. If a
+document and a link to it are received independently, e.g. as attachments in 
+separate e-mails, or a link to a document in the local intranet is e-mailed, 
+(all those links work :o .. this was also discussed in intro already (index))
+When people meet live, e.g. on a train, and form an ad-hoc network, they are
+able to see each other's documents and follow links to them if a
+peer-to-peer implementation of Storm is used (and pools published
+accordingly..? what should be discussed here?).
  
+*Tracking alternative versions*. Because Storm utilises immutable blocks,
+each modification to a document creates a new block. When a document is
+modified on several independent, unconnected systems, if there are
+simultaneous changes (i.e. no synching in between), there will be several  
+versions of it. Using diffs, each version is actually (a collection of)
+changes to the original. What happens then, is outside the scope of Storm:  
+the authors may decide to merge the changes forming a new joint version, but 
+how that is done is file format and hence application specific. If (some of)
+the new versions of the document are not merged but forked to separate
+branches, they simply continue to exist (they may be assigned different
+names, which is again outside the scope of Storm).
+
+.. some things from the earlier treatment left here as notes: 
+
+   B sets the document public (how that is done depends on UI
+   implementation), i.e.  putting in a published pool, which may reside
+   locally or externally e.g.  on a (dedicated) server that is "always-on".
+   These public/private zones are an area where future research is needed,
+   possibly related to rights and permissions etc. too.
+   
+   Comments may be new entities(?) linking to it   
+
 
 Open issue: Tree hashing, also possibly needed for (OceanStore-like?)
 distribution of shares