[Gzz-commits] manuscripts/storm article.rst

[Benja Fallenstein]

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

Modified files:
        storm          : article.rst 

Log message:
        slooooooow...

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.30 manuscripts/storm/article.rst:1.31
--- manuscripts/storm/article.rst:1.30  Wed Jan 22 05:11:32 2003
+++ manuscripts/storm/article.rst       Wed Jan 22 15:41:04 2003
@@ -5,11 +5,35 @@
 Introduction
 ============
 
-Many hypermedia systems place each document or link in the custody
+Many hypermedia systems place each document and link in the custody
 of one server, rendering it unusable when connectivity fails.
 For example, on the web, when connection to a server fails,
 links to documents on this server can generally not be followed.
-In Microcosm [ref], links are stored in *filters*, so when
+Open Hypermedia Systems such as Microcosm [ref] store links
+in *linkbases* on specific servers. In the Xanadu 88.1 design [ref],
+documents and links can be cached, but still have a 'home' server
+on which a 'master' copy is located. [XXX look more into it, correct xu terms]
+
+Such a system does not lend itself well to a world
+where servers fail, where clients are not 'always on,' and
+where documents regularly move from computer to computer in the form
+of email attachments. In a system where documents and links
+belong to one server, in a disconnected state documents
+cannot be retrieved and links cannot be followed.
+[XXX this isn't precise-- it's not true in this form]
+When documents are forwarded per email or downloaded from the Web today,
+links generally break.
+
+We propose a system implementing Xanalogical storage [ref Ted]
+based on global, location-independent identifiers, where
+document contents are named by cryptographical hashes [ref GUID paper].
+Assuming an index of all documents and links
+on the local computer and all systems that can be reached through
+the currently available network connections. Keeping such an
+index for the public Internet requires a decentralized,
+self-organizing distributed system (the IPTPS'03 definition
+of "peer-to-peer" [ref]).
+
 
 
 
@@ -79,6 +103,25 @@
 We archieve this by assigning documents and contents permanent,
 location-independent identifiers, and keeping an efficient (hemppah: should 
 we emphasize a *distributed* index ?) index of all data by its identity.
+
+----
+
+This type of system does not lend itself well to a world 
+where servers fail and clients are not permanently 'on.'
+Hypermedia functionality ought to be a service at the 
+operating system level, usable for organizing all data
+a user stores on their system [ref]. It is of course possible
+for a user to run an own, personal linkbase on their client system,
+
+In an ideal world, when users move documents between computers,
+links would not break, ...,
+different versions of documents could easily be reconciled,
+(file structure would not be lost). We envision a global identifier space,
+where links are created between global identifiers, and whenever
+any two endpoints of a link are known, this link can be shown.
+
+
+