[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Benja Fallenstein <address@hidden>      03/01/27 21:04:04

Modified files:
        storm          : article.rst 

Log message:
        More introduction work

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.40 manuscripts/storm/article.rst:1.41
--- manuscripts/storm/article.rst:1.40  Mon Jan 27 09:40:25 2003
+++ manuscripts/storm/article.rst       Mon Jan 27 21:04:04 2003
@@ -5,44 +5,49 @@
 1. Introduction
 ===============
 
-[Note: The following are my notes for what should be written,
-not final text! --benja .. adding comments in the middle --antont]
-
-The web: servers. {WebDAV}? Links break! Microcosm, alike;
-Xanadu, alike summat. (Tho no link breakage, given permanent ids.)
-[Read about Open Hypermedia work on permanent identifiers.]
-
-However, users do not live in a world of servers.
-Real-live data mobility. Server centricity not suited to this.
-It's well recognized that references should not be by location [ref URN].
+Documents move freely between 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. 
+Often, the same document will be independently modified 
+on two unconnected systems. We describe 
+the partially implemented Storm design, 
+a storage system designed to cope with two problems
+raised by moving documents: Dangling links [refs stating problem], 
+and keeping track of alternative versions [refs stating problem].
 
-->
 On the Web, documents are tightly bound to one location: they 
-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 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.
+cannot be moved to a different server without breaking links to them[#]_.
+It is the norm for hypermedia systems to bind documents to hosts,
+much like the Web. [Discuss Microcosm, Chimera and other OHS here. is it
+even wise to say it is the norm, if distributed hypermedia is a long trend?
+-- benja says: we're talking server-centric vs documents-not-bound-to-server,
+here; I believe most distributed hymedia sys are server-centric in this sense.]
 
 .. [#] 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. is it
-even wise to say it is the norm, if distributed hypermedia is a long trend?]
+Likewise, version control systems like CVS or RCS [ref] usually assume
+a central server hosting a repository. The WebDAV/DeltaV protocols,
+designed for interoperability between version control systems, inherit
+this assumption [ref]. On the other hand, Arch [ref] places all repositories
+into a global namespace and allows independent developers 
+to branch and merge overlapping repositories without any central control
+[is there a specific ref for this?].
+
 Even Xanadu [ref], which went a long way to ensure that links do not break
 when their targets are copied from one document to another,
 required permanent connection to a network of servers to function,
 and, at least in its 1988 incarnation [ref Green] addressed data 
 based on the address of a server holding a 'master copy.'
 
+
+
+[Note: The following are my notes for what should be written,
+not final text! --benja .. adding comments in the middle --antont]
+
+It's well recognized that references should not be by location [ref URN].
+
 (To explain data mobility:
 Data moves like this and that. The server/location paradigm
 is not suited to this: To support hypermedia functionality correctly,
@@ -195,6 +200,10 @@
 
 5. Versioning
 =============
+
+Clearly, for block storage to be useful, there has to be a way to
+update
+
 
 5.1. Pointers
 -------------