124 |
and versioning, while we use Xanalogical storage |
and versioning, while we use Xanalogical storage |
125 |
to address the movement of content between documents (copy&paste). |
to address the movement of content between documents (copy&paste). |
126 |
|
|
|
.. [XXX figure of the different layers in Storm] |
|
|
|
|
127 |
The main contribution of this paper is the Storm design, |
The main contribution of this paper is the Storm design, |
128 |
a hypermedia system built to use the emerging |
a hypermedia system built to use the emerging |
129 |
peer-to-peer search technologies to enhance data mobility. |
peer-to-peer search technologies to enhance data mobility. |
137 |
providing a platform for hypermedia-aware applications. |
providing a platform for hypermedia-aware applications. |
138 |
The peer-to-peer functionality is in a very early stage and not |
The peer-to-peer functionality is in a very early stage and not |
139 |
usable yet. |
usable yet. |
|
|
|
|
.. [Move somewhere else -b]: |
|
|
[Section 7 ?-) -Hermanni] |
|
|
No work on integrating Storm with current programs (in the spirit of Open Hypermedia) |
|
|
has been done so far. It is not clear how far this is possible |
|
|
without changing applications substantially, if advantage |
|
|
of our implementation of Xanalogical storage is to be taken. |
|
|
(Vitali [ref] notes that Xanalogical storage necessiates |
|
|
strong discipline in version tracking, which current systems lack.) |
|
|
|
|
|
.. Investigating the degrees of interoperability with Open Hypermedia |
|
|
(/Structural Computing?) and (more primitive?) other (Web) XXX is a possible |
|
|
direction for future work, and will be preliminarly discussed here too. |
|
|
[benja says: Really? Do we/can we discuss that really? antont: 'll try.] |
|
140 |
|
|
141 |
This paper is structured as follows. In the next section, we describe |
This paper is structured as follows. In the next section, we describe |
142 |
related work. In section 3, we introduce the basic storage unit of our |
related work. In section 3, we introduce the basic storage unit of our |
149 |
we report on implementation experience and future directions. |
we report on implementation experience and future directions. |
150 |
Section 8 concludes the paper. |
Section 8 concludes the paper. |
151 |
|
|
152 |
|
.. uml:: storm_layers |
153 |
|
|
154 |
|
package Blocks |
155 |
|
|
156 |
|
package Indexing |
157 |
|
use Blocks |
158 |
|
|
159 |
|
package XuStorage |
160 |
|
use Indexing |
161 |
|
use Blocks |
162 |
|
|
163 |
|
package Pointers |
164 |
|
use Indexing |
165 |
|
use Blocks |
166 |
|
|
167 |
|
package Diffs |
168 |
|
use Indexing |
169 |
|
use Blocks |
170 |
|
|
171 |
|
--- |
172 |
|
Blocks.c = (0,0); |
173 |
|
vertically(55, foo, Blocks, Indexing); |
174 |
|
|
175 |
|
dx = 80; dy = 60; |
176 |
|
XuStorage.c = Indexing.c + (-dx, -dy); |
177 |
|
z1 = Indexing.c + (dx, -dy); |
178 |
|
Pointers.c = z1 + (15, 25); |
179 |
|
Diffs.c = z1 - (15, 15); |
180 |
|
|
181 |
.. [Use cases in intro, discussion on how Storm applies to them |
.. [Use cases in intro, discussion on how Storm applies to them |
182 |
to the end/in Conclusions.] |
to the end/in Conclusions.] |
183 |
|
|
998 |
the difference from ``A`` to ``C``, and replace the two |
the difference from ``A`` to ``C``, and replace the two |
999 |
previous differences by it. If we also store a difference |
previous differences by it. If we also store a difference |
1000 |
between version ``C`` and ``D``, it does not need |
between version ``C`` and ``D``, it does not need |
1001 |
to be altered, because it refers to *version ``C``* and not |
to be altered, because it refers to *version* ``C`` and not |
1002 |
the difference to ``C`` from ``B`` (as in the simplistic scheme). |
the difference to ``C`` from ``B`` (as in the simplistic scheme). |
1003 |
|
|
1004 |
[XXX Figure: diffs from a->b, b->c, c->d; we replace |
.. [XXX Figure: diffs from a->b, b->c, c->d; we replace |
1005 |
the diffs a->b and b->c by a single diff a->c.] |
the diffs a->b and b->c by a single diff a->c.] |
1006 |
|
|
1007 |
We can also store the block containing version ``D`` |
We can also store the block containing version ``D`` |
1008 |
in addition to storing the versions above. Then, we can reconstruct |
in addition to storing the versions above. Then, we can reconstruct |
1014 |
that can be 'skipped' will have to be much higher |
that can be 'skipped' will have to be much higher |
1015 |
for this mechanism to be useful. |
for this mechanism to be useful. |
1016 |
|
|
1017 |
[XXX fig?] |
.. [XXX fig?] |
1018 |
|
|
1019 |
Our current implementation is a layer above Storm block storage |
Our current implementation is a layer above Storm block storage |
1020 |
and indexing. This layer implements a ``load(version-id) -> version`` |
and indexing. This layer implements a ``load(version-id) -> version`` |
1180 |
might allow for the (even substantial) changes that 'xanalogicalising' it |
might allow for the (even substantial) changes that 'xanalogicalising' it |
1181 |
would mean in practise. For Gzz, Zope might provide a window to the Web. |
would mean in practise. For Gzz, Zope might provide a window to the Web. |
1182 |
|
|
1183 |
|
.. Investigating the degrees of interoperability with Open Hypermedia |
1184 |
|
(/Structural Computing?) and (more primitive?) other (Web) XXX is a possible |
1185 |
|
direction for future work, and will be preliminarly discussed here too. |
1186 |
|
[benja says: Really? Do we/can we discuss that really? antont: 'll try.] |
1187 |
|
|
1188 |
(Also about OHProtocol? will check) |
(Also about OHProtocol? will check) |
1189 |
|
|
1190 |
When Xanalogical storage is not applied, using Storm as a |
When Xanalogical storage is not applied, using Storm as a |
1210 |
8. Conclusions |
8. Conclusions |
1211 |
============== |
============== |
1212 |
|
|
1213 |
XXX |
We have presented the Storm design, which makes use of recent advances |
1214 |
|
in peer-to-peer technology to support many different forms |
1215 |
|
of data mobility. All data is stored in immutable blocks, |
1216 |
|
of which application-specific indices can be kept. On top of |
1217 |
|
indexed blocks, we implement efficient versioned storage |
1218 |
|
of mutable resources as well as Xanalogical storage. |
1219 |
|
|
1220 |
|
Storm is not limited to network publishing; |
1221 |
|
it is intended to be used for private documents stored on |
1222 |
|
desktop systems as well. Our current implementation does not support |
1223 |
|
peer-to-peer distribution yet, but the Gzz project has used it |
1224 |
|
for local storage and server-based collaboration |
1225 |
|
for one and a half years. |
1226 |
|
|
1227 |
|
Storm has proven to be a solid basis for Gzz, but |
1228 |
|
no work has been done to integrate it with existing systems, yet. |
1229 |
|
This makes Storm a rather monolithic approach at present. |
1230 |
|
However, even if Storm-- or especially Xanalogical storage-- |
1231 |
|
should be hard to integrate with existing systems, |
1232 |
|
we believe that it is valuable as an exercise in what is possible |
1233 |
|
if we can break backwards compatibility with the state of the art. |
1234 |
|
|
1235 |
|
At the very least, we hope to provide a case study in |
1236 |
|
what's possible in a system that does not use |
1237 |
|
location-dependent identifiers at all. We hope to raise awareness |
1238 |
|
for the prospects of location-independent systems based |
1239 |
|
on structured overlay networks like DHTs. |
1240 |
|
|
1241 |
|
|
1242 |
9. Acknowledgements |
9. Acknowledgements |