/[gzz]/manuscripts/storm/article.rst
ViewVC logotype

Diff of /manuscripts/storm/article.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.54 by hemppah, Wed Jan 29 10:21:48 2003 UTC revision 1.55 by antont, Wed Jan 29 10:24:07 2003 UTC
# Line 2  Line 2 
2  Don't fence me in: Supporting data mobility through the Gzz/Storm design  Don't fence me in: Supporting data mobility through the Gzz/Storm design
3  ========================================================================  ========================================================================
4    
5    (an-other way (too buzzwordy? but generalized!): enabling distributed
6    mobile hypermedia with location independent unique document identifiers)
7    
8  1. Introduction  1. Introduction
9  ===============  ===============
10    
# Line 22  In this paper, we present Storm, a desig Line 25  In this paper, we present Storm, a desig
25  dangling links and keeping track of alternative versions,  dangling links and keeping track of alternative versions,
26  taking advantage of these new developments.  taking advantage of these new developments.
27    
28  On the Web, documents are tightly bound to one location: they  On the Web, documents are tightly bound to one location: they cannot be
29  cannot be moved to a different server without breaking links to them[#]_.  moved to a different server without breaking links to them[#]_. It is the
30  It is the norm for hypermedia systems to bind documents to hosts,  norm for hypermedia systems to bind documents to hosts, much like the Web.
31  much like the Web. [Discuss Microcosm, Chimera and other OHS here. is it  However, in advanced hypermedia systems such as Microcosm[] and Hyper-G[],
32  even wise to say it is the norm, if distributed hypermedia is a long trend?  several approaches to dealing with the dangling link and other link
33  -- benja says: we're talking server-centric vs documents-not-bound-to-server,  management problems have been developed. Microcosm addressed the linking
34    problems of large archives by separating the links from the documents and
35    storing them on dedicated linkbases, with the requirement that when a
36    document where a position or document dependant link anchor occurs is moved
37    or deleted, the hypermedia document management system, or hyperbase, ought
38    to be informed [HymEbook?]. In Hyper-G, when there are similar changes, all
39    other Hyper-G servers that reference that document can be informed, and an
40    efficient protocol has been proposed for that purpose [kappe95scalable].
41    (All that does not change the basic assumption, may even be seen as
42    workarounds from the p2p solution's point of view?)
43    [yet Chimera and other OHS?]
44    -- agreed: we're talking server-centric vs documents-not-bound-to-server,
45  here; I believe most distributed hymedia sys are server-centric in this sense.]  here; I believe most distributed hymedia sys are server-centric in this sense.]
46    
47  .. [#] Except if the new server is a complete replacement for the old,  .. [#] Except if the new server is a complete replacement for the old,

Legend:
Removed from v.1.54  
changed lines
  Added in v.1.55

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26