[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/01/25 12:51:34

Modified files:
        storm          : article.rst 

Log message:
        bit

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.35 manuscripts/storm/article.rst:1.36
--- manuscripts/storm/article.rst:1.35  Sat Jan 25 08:11:48 2003
+++ manuscripts/storm/article.rst       Sat Jan 25 12:51:33 2003
@@ -18,17 +18,21 @@
 
 ->
 On the Web, documents are tightly bound to one location: they 
-cannot be moved to a different server without breaking links to them. 
+cannot be moved to a different server without breaking links to them[#]_. 
 This paradigm may be tolerable for published data, but it mixes
 badly with data on desktop computers, since users expect to
 move data quite freely, copying it through the network,
 taking it home on diskettes, sending it in e-mail attachments,
 or moving it between their desktop and laptop computers.
 Documents are copied from the Web to local storage for off-line reading.
-We examine two issues this *data mobility* raises for hypermedia:
+We present a design that addresses two issues 
+this *data mobility* raises for hypermedia:
 keeping track of links, and keeping track of alternative versions
 as documents move between computers.
 
+.. [#] Except if the new server is a complete replacement for the old,
+   inheriting its Internet domain.
+
 ->
 It is the norm for hypermedia systems to assume a centralized infrastructure,
 much like the Web. [Discuss Microcosm, Chimera and other OHS here.]
@@ -38,9 +42,6 @@
 and, at least in its 1988 incarnation [ref Green] addressed data 
 based on the address of a server holding a 'master copy.'
 
-->
-
-
 (To explain data mobility:
 Data moves like this and that. The server/location paradigm
 is not suited to this: To support hypermedia functionality correctly,
@@ -49,9 +50,16 @@
 and online publishing into one.)
 
 Server centricity is what made the web scalable. Backlinks rejected
-for this reason [ref TBL]. However, recent innovations in P2P have made
+for this reason [ref TBL -- XXX note: not true like this; the ref I had
+in mind is http://www.w3.org/DesignIssues/NameMyth.html, and
+it's not about back links]. However, recent innovations in P2P have made
 scalable hashtables possible.
 
+->
+Binding documents to servers has been necessary to make the Web scalable:
+
+
+
 {If standards could be agreed on, web servers should be able to
 self-organize into a DHT implementing bidi links. There has been
 interest in p2p hypermedia [ref Bouvin]. This would not, however,
@@ -93,6 +101,14 @@
 
 2. Block storage
 ================
+
+In our system, Storm (for *storage module*), all data is stored
+in *blocks*, byte sequences identified by a
+cryptographic hash. Blocks often have a similar granularity
+as files, but they are immutable, since any change to the
+byte sequence would change the hash (and thus create a different block).
+
+
 
 3. Xanalogical storage
 ======================