[Gzz-commits] manuscripts/storm article.rst

[Toni Alatalo]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Changes by:     Toni Alatalo <address@hidden>   03/01/29 05:24:07

Modified files:
        storm          : article.rst 

Log message:
        a thought on the title. some integration from link_management.txt

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

Patches:
Index: manuscripts/storm/article.rst
diff -u manuscripts/storm/article.rst:1.54 manuscripts/storm/article.rst:1.55
--- manuscripts/storm/article.rst:1.54  Wed Jan 29 05:21:48 2003
+++ manuscripts/storm/article.rst       Wed Jan 29 05:24:07 2003
@@ -2,6 +2,9 @@
 Don't fence me in: Supporting data mobility through the Gzz/Storm design
 ========================================================================
 
+(an-other way (too buzzwordy? but generalized!): enabling distributed
+mobile hypermedia with location independent unique document identifiers)
+
 1. Introduction
 ===============
 
@@ -22,12 +25,23 @@
 dangling links and keeping track of alternative versions,
 taking advantage of these new developments.
 
-On the Web, documents are tightly bound to one location: they 
-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,
+On the Web, documents are tightly bound to one location: they 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.
+However, in advanced hypermedia systems such as Microcosm[] and Hyper-G[],
+several approaches to dealing with the dangling link and other link
+management problems have been developed. Microcosm addressed the linking
+problems of large archives by separating the links from the documents and
+storing them on dedicated linkbases, with the requirement that when a
+document where a position or document dependant link anchor occurs is moved
+or deleted, the hypermedia document management system, or hyperbase, ought
+to be informed [HymEbook?]. In Hyper-G, when there are similar changes, all
+other Hyper-G servers that reference that document can be informed, and an
+efficient protocol has been proposed for that purpose [kappe95scalable].
+(All that does not change the basic assumption, may even be seen as
+workarounds from the p2p solution's point of view?)
+[yet Chimera and other OHS?]
+-- agreed: 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,