6 |
======== |
======== |
7 |
|
|
8 |
We define data mobility as a collective term for the |
We define data mobility as a collective term for the |
9 |
movement of documents between computers, locations on one computer and |
movement of documents between computers, different locations on one computer and |
10 |
movement of content between documents. |
movement of content between documents. |
11 |
We identify dangling links, tracking identity and alternative versions as |
We identify dangling links, tracking identity and alternative versions as |
12 |
obstacles for the free movement of data, |
obstacles for the free movement of data, and review |
|
and review |
|
13 |
motivations and potential solutions in existing hypermedia research. |
motivations and potential solutions in existing hypermedia research. |
14 |
We discuss some specific use scenarios, related to ad hoc networks, |
We discuss some specific use scenarios, related to ad hoc networks, |
15 |
unreliable network connections and mobile computing |
unreliable network connections and mobile computing |
19 |
|
|
20 |
We present Storm (STORage Module) design as one possible solution |
We present Storm (STORage Module) design as one possible solution |
21 |
to the problems in the above scenarios. |
to the problems in the above scenarios. |
22 |
Storm uses |
Storm uses location-independent, globally unique identifiers, |
23 |
location-independent globally unique identifiers, immutable block storage |
immutable block storage and peer-to-peer networking to .... |
|
and peer-to-peer networking to .... |
|
24 |
|
|
25 |
Our current, partial implementation ... |
Our current, partial implementation ... |
26 |
|
|
33 |
|
|
34 |
Keywords: hypermedia, versioned hypermedia, dangling links, xanalogical storage, P2P, |
Keywords: hypermedia, versioned hypermedia, dangling links, xanalogical storage, P2P, |
35 |
peer-to-peer, location-independent identifiers, location-independent routing, |
peer-to-peer, location-independent identifiers, location-independent routing, |
36 |
distributed hashtables |
distributed hashtables, DHT |
37 |
|
|
38 |
|
|
39 |
1. Introduction |
1. Introduction |
102 |
on the public Internet. |
on the public Internet. |
103 |
|
|
104 |
Location-independent identifiers for documents |
Location-independent identifiers for documents |
105 |
make such a system unnecessary; a peer-to-peer lookup system |
make such a system unnecessary; a structured peer-to-peer lookup system |
106 |
can find documents wherever they are moved. |
can find documents wherever they are moved. |
107 |
Such a system also works for data not publicized on the Internet. |
This kind of system also works for data not publicized on the Internet. |
108 |
For example, if one email has a document attached to it, and another email |
For example, if one email has a document attached to it, and another email |
109 |
links to this document, an index of locally stored documents |
links to this document, an index of locally stored documents |
110 |
by permanent identifier allows the system to follow the link. |
by permanent identifier allows the system to follow the link. |
126 |
to work on the version at hand and then either merge it with others |
to work on the version at hand and then either merge it with others |
127 |
or fork to a different branch. |
or fork to a different branch. |
128 |
|
|
129 |
In this paper, we present Storm (for *storage module*), a design |
In this paper, we present Storm (for *STOrage Module*), a design |
130 |
dealing with versioning and dangling links. Storm is a library |
dealing with versioning and dangling links. Storm is a library |
131 |
for storing and retrieving data as *blocks*, immutable |
for storing and retrieving data as *blocks*, immutable |
132 |
byte sequences identified by cryptographic content hashes |
byte sequences identified by cryptographic content hashes |
138 |
|
|
139 |
The main contribution of this paper is the Storm design, |
The main contribution of this paper is the Storm design, |
140 |
a hypermedia system built to use the emerging |
a hypermedia system built to use the emerging |
141 |
peer-to-peer search technologies to enhance data mobility. |
peer-to-peer data lookup technologies to enhance data mobility. |
142 |
Additionally, we hope to |
Additionally, we hope to |
143 |
provide an input to the ongoing discussion about peer-to-peer |
provide an input to the ongoing discussion about peer-to-peer |
144 |
hypermedia systems [ref ht01, ht02]. |
hypermedia systems [ref ht01, ht02]. |
|
|
|
145 |
Currently, Storm is partially implemented as a part of the Gzz |
Currently, Storm is partially implemented as a part of the Gzz |
146 |
project [ref], which uses Storm exclusively for all disk storage. |
project [ref], which uses Storm exclusively for all disk storage. |
147 |
Gzz is an implementation of Ted Nelson's zzstructure [ref], |
Storm's peer-to-peer functionality is in a very early stage and not |
|
providing a platform for hypermedia-aware applications. |
|
|
The peer-to-peer functionality is in a very early stage and not |
|
148 |
usable yet. |
usable yet. |
149 |
|
|
150 |
This paper is structured as follows. In the next section, we describe |
This paper is structured as follows. In the next section, we describe |
383 |
|
|
384 |
.. Should we discuss applications of p2p systems (CFS, OceanStore, Squirrel, ...) |
.. Should we discuss applications of p2p systems (CFS, OceanStore, Squirrel, ...) |
385 |
here? If so, which ones? |
here? If so, which ones? |
386 |
|
[CFS/PAST(DHT, GUID, block vs. files), perhaps Freenet too (GUID) ? -Hermanni] |
387 |
|
|
388 |
.. thesis-benja: remove paragraph below |
.. thesis-benja: remove paragraph below |
389 |
|
|
969 |
due Feb 9th, so I want all possible improvements on it |
due Feb 9th, so I want all possible improvements on it |
970 |
to go there, too ;-) [and I'm of course allowed to solicite feedback, |
to go there, too ;-) [and I'm of course allowed to solicite feedback, |
971 |
but not allowed to use stuff written by someone else...]] |
but not allowed to use stuff written by someone else...]] |
972 |
|
[Hm, should we move/remove 'Additionally, many versioning' |
973 |
|
paragraph into related work ? -Hermanni] |
974 |
|
|
975 |
The pointer system suggests that for each version of a document, |
The pointer system suggests that for each version of a document, |
976 |
we store an independent block containing this version. This |
we store an independent block containing this version. This |
1257 |
|
|
1258 |
One possibility: Use IBP for limited-time publishing, referring to |
One possibility: Use IBP for limited-time publishing, referring to |
1259 |
the location through the DHT? This might be related to p2p publishing. |
the location through the DHT? This might be related to p2p publishing. |
1260 |
|
|
1261 |
|
|
1262 |
8. Conclusions |
8. Conclusions |
1263 |
============== |
============== |
1284 |
we believe that it is valuable as an exercise in what is possible |
we believe that it is valuable as an exercise in what is possible |
1285 |
if we can break backwards compatibility with the state of the art. |
if we can break backwards compatibility with the state of the art. |
1286 |
|
|
1287 |
At the very least, we hope to provide a case study in |
At the end, we hope that we have provided a case study in |
1288 |
what's possible in a system that does not use |
what's possible in a system that does not use |
1289 |
location-dependent identifiers at all. We hope to raise awareness |
location-dependent identifiers at all. We hope to raise awareness |
1290 |
for the prospects of location-independent systems based |
for the prospects of location-independent systems based |
1291 |
on structured overlay networks like DHTs. |
on structured overlay networks such as DHTs. |
1292 |
|
|
1293 |
|
|
1294 |
9. Acknowledgements |
9. Acknowledgements |