[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

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

Modified files:
        storm          : article.rst 

Log message:
        leaner and a bit meaner

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.160 manuscripts/storm/article.rst:1.161
--- manuscripts/storm/article.rst:1.160 Sat Feb 15 09:21:57 2003
+++ manuscripts/storm/article.rst       Sat Feb 15 09:34:40 2003
@@ -201,7 +201,7 @@
 has been moved, and redirect it accordingly [rfc2068]_. However,
 this is not required, and there are no facilities for
 updating a link automatically when its target is moved.
-The HTTP protocol does include a "LINK" request 
+The HTTP protocol includes a "LINK" request 
 for creating a relationship between a set of URIs, 
 but this feature has never been commonly implemented [reich-davis99-ohp]_.
 
@@ -575,31 +575,31 @@
    the basic assertion holds.
 
 Even when a publisher's server fails to serve a block,
-links to it will not cease to work until *no* other peer
-holds a copy. This means that providing mirrors is trivial.
+links to it will work until *no* other peer
+holds a copy. Thus, providing mirrors is trivial.
 Even after failure of all of the publisher's mirrors,
 a document may still be available from peers that have
 downloaded it. An archive of published blocks, in the spirit
-of the Web archive [waybackmachine]_, would only be yet another backup;
+of the Web archive [waybackmachine]_, would only be yet another backup:
 normal links to a block would work as long as the archive
 holds a copy. It would also be hard to purposefully remove
 a published document from the network; whether this is
 a good or a bad property we leave for the reader to judge.
 
 Finally, because blocks are easy to move from system
-to system, we hope that block storage may be more *durable* than files.
+to system, we hope that block storage will be more *durable* than files.
 When users own multiple systems, or buy new systems
 to replace old ones, files are often on one harddisk
-and not the other, or moved to an old floppy disk but not back
+and not the other, or moved to a floppy disk but not back
 to the harddisk. How many files you created in the 80s
 do you still keep around on your harddisk today? With block storage,
-each time you buy a new computer, it would be possible
-to transfer all blocks from your existing systems to the new one,
-and if you left some lying around on a floppy, you would be able
-to copy it to your harddisk without thinking about issues
-like which directory to keep it in. By making it easy to collect
+each time a user buys a new computer, they could
+transfer all blocks from their existing systems to the new one,
+and blocks from old floppies could be copied to the harddisk
+without thinking about issues like which directory 
+to keep them in. By making it easy to collect
 blocks produced on a diverse number of systems, it would be easier
-to actually keep that old data around.
+to keep old data around.
 
 Of course, to meet this goal it is necessary that the block
 system remains backwards compatible at all times. We have therefore
@@ -660,38 +660,7 @@
 table of known peers, and issues with UDP and network
 address translation [rfc3253]_).
 
-Sometimes it is useful to think about *zones* blocks are in,
-related to distribution policy: for example, a *public*
-zone for blocks served to others in the network, a *private*
-zone for a user's own data, and a *local* zone with blocks
-served to anyone on the local intranet. It is essential
-that blocks from a private zone are not leaked into a public 
-zone without the user's consent. On the other hand, making
-a document available on the network should be as easy as
-hitting a 'publish' button moving it to a public zone,
-possibly also uploading it to a server permanently connected
-to the Internet, if one is available.
-
-We have unfortunately not found a satisfactory representation
-of zones yet. In particular, how do we decide which zone
-a new block should be in? Probably in the private zone
-in many cases, but if we have been editing a document
-collaboratively edited in a workgroup, we would want
-our changes to be available to the same group.
-
-An important open issue with block storage are
-UI conventions for listing, moving and deleting blocks.
-Currently, the only interface is a file system directory
-containing a set of blocks as files with hexadecimal, 
-random-looking names. In Gzz, we currently trick our way around
-the problem; at startup time, we simply load the most current
-version of a document whose identifier is hard-wired into
-the software (mutable documents are described in section 6.1).
-
-4.2. Xanalogical storage on top of blocks
------------------------------------------
-
-In Storm, in each editor session we 
+To implement *Xanalogical storage* in Storm, in each editor session we 
 create a block with all characters entered in this session (the content type
 being ``text/plain``). To designate a span of characters
 from that session, we use the block's id, the offset of the first
@@ -700,9 +669,9 @@
 
 In Xanadu, characters are stored to append-only *scrolls*
 when they are typed [ref?]. Because of this, in Storm, we call the 
-blocks containing the actual characters *scroll blocks*. The documents
-do not actually contain the characters; instead, they are
-*virtual files* containing span references as described above.
+blocks containing the actual characters *scroll blocks*. Documents
+do not actually contain characters; instead, they are
+*virtual files* containing references to spans.
 To show a document, the scroll blocks it references are loaded
 and the characters retrieved from there [#]_.
 
@@ -715,6 +684,16 @@
    stored once, in a block only referred to wherever
    the data is transcluded.
 
+An important open issue with block storage are
+UI conventions for listing, moving and deleting blocks.
+
+.. Currently, the only interface is a file system directory
+   containing a set of blocks as files with hexadecimal, 
+   random-looking names. In Gzz, we currently trick our way around
+   the problem; at startup time, we simply load the most current
+   version of a document whose identifier is hard-wired into
+   the software (mutable documents are described in section 6.1).
+
 
 5. Application-specific reverse indexing
 ========================================
@@ -881,7 +860,7 @@
 for off-line as well as on-line work.
 For long-term publishing, one-time signatures have been
 found useful [anderson98erl]_. For the time being, the pointer mechanism
-works only in trusted Storm zones (Section 4), e.g.
+works only in trusted Storm pools (Section 4), e.g.
 in a workgroup collaborating on a set of documents.
 
 .. [#] Without timestamps, digital signatures are only valid
@@ -1117,7 +1096,7 @@
    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,
+   These public/private pools are an area where future research is needed,
    possibly related to rights and permissions etc. too.
    
    Comments may be new entities(?) linking to it