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 |
|
|
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, |