58 |
Dangling links and keeping track of alternative versions. |
Dangling links and keeping track of alternative versions. |
59 |
Resolvable location independent identifiers |
Resolvable location independent identifiers |
60 |
make these issues much easier to deal with, since data |
make these issues much easier to deal with, since data |
61 |
can be recognized whereever it is moved. {{The design also allows for |
can be recognized whereever it is moved. |
62 |
|
|
63 |
|
{{The design also allows for |
64 |
automatic balancing of the load, which occurs in location-dependent |
automatic balancing of the load, which occurs in location-dependent |
65 |
situations with popular items.}} |
situations with popular items. [benja says: This is not related |
66 |
|
to the central point as expressed in the title; therefore, I believe |
67 |
|
it should be given as a benefit of the system somewhere later |
68 |
|
in the paper (like many others) but not put here...]}} |
69 |
|
|
70 |
|
Advanced hypermedia systems such as Microcosm and Hyper-G |
71 |
|
address dangling links through a notification system: |
72 |
|
When a document is moved, servers storing links to it are notified. |
73 |
|
Hyper-G uses an efficient protocol for delivering such notifications |
74 |
|
on the public Internet. |
75 |
|
|
76 |
|
The use of location-independent identifiers |
77 |
|
for documents, resolved through a peer-to-peer lookup system, |
78 |
|
makes such a notification unnecessary; when a document is moved, |
79 |
|
but retains its identifier, it can be found by the same mechanism as |
80 |
|
before the move. It is possible to retrieve the document |
81 |
|
from any system storing a copy; this means that documents may be |
82 |
|
accessible even after the original publisher has taken them off-line [#]_. |
83 |
|
|
84 |
|
.. [#] Intentionally or unintentionally. We believe that it is |
85 |
|
a good thing if published documents remain available even when |
86 |
|
the original publisher wants to retract them; however, discussion |
87 |
|
of the ethical implications of this is outside the scope of this paper. |
88 |
|
(But see [XXX search for refs! ;-)]) |
89 |
|
|
90 |
|
Such a system also works for data not publicized on the Internet. |
91 |
|
For example, if one email has a document attached to it, and another email |
92 |
|
links to this document, an index of locally stored documents |
93 |
|
by permanent identifier allows the system to follow the link. |
94 |
|
This would be extremely difficult to realize through a |
95 |
|
notification mechanism like Microcosm's and Hyper-G's. |
96 |
|
|
97 |
|
XXX say something about versioning |
98 |
|
|
99 |
In this paper, we present Storm (for *storage module*), a design |
In this paper, we present Storm (for *storage module*), a design |
100 |
dealing with these issues. Storm is a library |
dealing with these issues. Storm is a library |
101 |
for storing and retrieving data in immutable |
for storing and retrieving data as immutable |
102 |
byte sequences identified by cryptographic content hashes |
byte sequences identified by cryptographic content hashes |
103 |
[ref ht'02 paper], unifying the namespaces of |
[ref ht'02 paper], unifying the namespaces of |
104 |
private data and documents published on the Internet by |
private data and documents published on the Internet by |
105 |
using the same identifiers for both. Storm provides services |
using the same identifiers for both. Storm provides services |
106 |
for storing versioned data and Xanalogical storage [ref]. |
for versioned data and Xanalogical storage [ref]. |
107 |
The Storm design, a hypermedia system built to make use |
The Storm design, a hypermedia system built to make use |
108 |
of the emerging peer-to-peer search technologies, |
of the emerging peer-to-peer search technologies, |
109 |
is the main contribution of this paper. |
is the main contribution of this paper. |