365 |
system relying only on the abstraction presented |
system relying only on the abstraction presented |
366 |
in the previous section. |
in the previous section. |
367 |
|
|
368 |
|
|
369 |
|
|
370 |
.. - In this section, we discuss a particular way |
.. - In this section, we discuss a particular way |
371 |
of implementing pointers (this is our main contribution) |
of implementing pointers (this is our main contribution) |
372 |
- The association between a pointer and a version is formed |
- The association between a pointer and a version is formed |
377 |
- Signatures |
- Signatures |
378 |
- Timestamp for ordering the records/versions (note on problems |
- Timestamp for ordering the records/versions (note on problems |
379 |
this entails-- if a computer's clock is set into future etc) |
this entails-- if a computer's clock is set into future etc) |
380 |
|
- explicit obsoletion of pointers |
381 |
|
|
382 |
|
|
|
- Implementable in other systems, too [XXX is this still a point |
|
|
given that OceanStorm does something similar?] |
|
383 |
- Carries over the four benefits from hash-based addressing: |
- Carries over the four benefits from hash-based addressing: |
384 |
|
|
385 |
- Version references movable between servers |
- Version references movable between servers |
388 |
- Can use one addressing scheme for *updateable* information, |
- Can use one addressing scheme for *updateable* information, |
389 |
searching different networks for versions |
searching different networks for versions |
390 |
|
|
391 |
|
- Implementable in any system providing the above features, |
392 |
|
too [XXX is this still a point |
393 |
|
given that OceanStorm does something similar?] think |
394 |
|
|
395 |
Diffs |
Diffs |
396 |
===== |
===== |
424 |
- ... |
- ... |
425 |
|
|
426 |
|
|
427 |
|
Implementation |
428 |
|
============== |
429 |
|
|
430 |
|
- ? |
431 |
|
|
432 |
Conclusions |
Conclusions |
433 |
=========== |
=========== |
434 |
|
|
435 |
|
- COUNTERARGUMENTS THAT NEED TO BE ADDRESSED: |
436 |
|
- efficiency? Storing lots of versions could get inefficient, |
437 |
|
especially on the part of indexing the pointers in the system. |
438 |
|
If there are 1000 000 000 or more pointer blocks of a single pointer, |
439 |
|
what part of the system fails, if any? |
440 |
|
- will be there only if someone *wants* to store those versions |
441 |
|
unwanted versions get purged |
442 |
|
- spamming with new versions (only author due to DS, but still) |
443 |
|
|
444 |
- XXX |
- XXX |
445 |
- We have presented a peer-to-peer infrastructure that...with location-independent |
- We have presented a peer-to-peer infrastructure that...with location-independent |
446 |
identifiers |
identifiers |