275 |
version x to a link representing version y even if version y |
version x to a link representing version y even if version y |
276 |
does not exist in a system yet. |
does not exist in a system yet. |
277 |
|
|
278 |
|
.. ??? XXX I don't understand the above AT ALL |
279 |
|
|
280 |
Basic model |
Basic model |
281 |
=========== |
=========== |
282 |
|
|
283 |
- Basic model of underlying system: Only blocks |
Our goal is to build a complete system of versioning |
284 |
- Benefits of that, in a nutshell |
on top of the following primitive abstraction provided |
285 |
- Reverse indexing (nicely provided through structured overlays), |
by a system: |
286 |
*define* reverse indexing |
|
287 |
- Def.: Pointers are abstract references that *point* |
Add permanent block |
288 |
to different blocks (versions) over time |
Given a bit string, adds the block into |
289 |
- Storm is designed to be modular; different routing algorithms |
the system and return a *permanent id* for |
290 |
can be used with Storm for locating data with loc.ind. ids ( |
that exact bitstring, |
291 |
(e.g., PAST and CFS are tightly binded to their routing |
for example a cryptographic hash of the data. |
292 |
algorithm) |
|
293 |
|
Get the permanent data for a given id |
294 |
|
Given a permanent id, locate and return the bitstring |
295 |
|
stored with that permanent id, or inform the caller |
296 |
|
that the data was not currently available. |
297 |
|
|
298 |
|
Global reverse indices |
299 |
|
The ability to define (on a system-wide basis) |
300 |
|
partial functions of blocks (of the data in the bitstrings) |
301 |
|
and to query for the ids |
302 |
|
(and thus the data) |
303 |
|
of the blocks with the given values for the functions. |
304 |
|
|
305 |
|
For scalability, the ability to also define another |
306 |
|
function, which takes a set of blocks and determines which |
307 |
|
of the blocks are "relevant" locally on each peer can yield |
308 |
|
great improvements. |
309 |
|
|
310 |
|
Managing where the blocks are stored is excluded |
311 |
|
from the scope of this abstraction. The versioning system |
312 |
|
must work as best it can even if only a subset of the |
313 |
|
blocks is available. |
314 |
|
|
315 |
|
The benefits of starting from this basic model are numerous: |
316 |
|
XXX |
317 |
|
|
318 |
|
.. - Basic model of underlying system: Only blocks |
319 |
|
- Benefits of that, in a nutshell |
320 |
|
- Reverse indexing (nicely provided through structured overlays), |
321 |
|
*define* reverse indexing |
322 |
|
- Def.: Pointers are abstract references that *point* |
323 |
|
to different blocks (versions) over time |
324 |
|
- Storm is designed to be modular; different routing algorithms |
325 |
|
can be used with Storm for locating data with loc.ind. ids ( |
326 |
|
(e.g., PAST and CFS are tightly binded to their routing |
327 |
|
algorithm) |
328 |
|
|
329 |
|
|
330 |
Pointer records |
Pointer records |
414 |
may be academic articles, in which references to other articles |
may be academic articles, in which references to other articles |
415 |
are ideally to an immutable version, and in which references |
are ideally to an immutable version, and in which references |
416 |
are generally not circular, making this domain map neatly |
are generally not circular, making this domain map neatly |
|
to the properties of hash-based referencing. |
|
417 |
|
to the properties of hash-based referencing. |