201 |
available CFS servers. Freenet [ref] and PAST [ref, pastry ref] doesn't split |
available CFS servers. Freenet [ref] and PAST [ref, pastry ref] doesn't split |
202 |
files into blocks, since they store data as whole files. All previously mentioned |
files into blocks, since they store data as whole files. All previously mentioned |
203 |
systems lack of the immutable property which is used in Storm blocks. |
systems lack of the immutable property which is used in Storm blocks. |
|
|
|
204 |
|
|
205 |
Related work: we need something about p2p hypermedia: |
Related work: we need something about p2p hypermedia: |
206 |
[ref Bouvin, Wiil ("Peer-to-Peer Hypertext")] |
[ref Bouvin, Wiil ("Peer-to-Peer Hypertext")] |
207 |
|
|
|
[Note: The following are my notes for what should be written, |
|
|
not final text! --benja .. adding comments in the middle --antont] |
|
|
|
|
208 |
It's well recognized that references should not be by location [ref URN]. |
It's well recognized that references should not be by location [ref URN]. |
209 |
|
|
|
(To explain ad hoc *data mobility*: |
|
|
Data moves like this and that. The server/location paradigm |
|
|
is not suited to this: To support hypermedia functionality correctly, |
|
|
we need to recognize two copies of the *same* document. |
|
|
Only then can we merge the fragmented worlds of desktop computing |
|
|
and online publishing into one.) |
|
|
|
|
|
Server centricity is what made the web scalable. Backlinks rejected |
|
|
for this reason [ref TBL -- XXX note: not true like this; the ref I had |
|
|
in mind is http://www.w3.org/DesignIssues/NameMyth.html, and |
|
|
it's not about back links]. However, recent innovations in P2P have made |
|
|
scalable location independent routing/hashtables possible. |
|
|
|
|
|
-> |
|
|
Binding documents to servers has been necessary to make the Web scalable, |
|
|
as no central index of documents was needed. |
|
|
Berners-Lee [ref NameMyth] argues that identifying documents |
|
|
by unique, completely random identifiers may be desirable because |
|
|
there is never a need to change such an identifier because e.g. a server |
|
|
moves to a different organization, but that it is not possible to |
|
|
resolve |
|
|
|
|
|
|
|
210 |
{If standards could be agreed on, web servers should be able to |
{If standards could be agreed on, web servers should be able to |
211 |
self-organize into a DHT implementing bidi links. There has been |
self-organize into a DHT implementing bidi links. There has been |
212 |
interest in p2p hypermedia [ref Bouvin, Wiil ("Peer-to-Peer Hypertext")]. |
interest in p2p hypermedia [ref Bouvin, Wiil ("Peer-to-Peer Hypertext")]. |
267 |
To support hypermedia functionality well in these cases, we need to |
To support hypermedia functionality well in these cases, we need to |
268 |
address the issues above. |
address the issues above. |
269 |
|
|
|
We present a design which addresses the issues we have raised. |
|
|
We are currently in prototype stage, which we describe... |
|
|
Along with the design, we illustrate how it supports various situations in |
|
|
the use cases. |
|
|
|
|
|
-> |
|
|
We present Storm (for *storage module*), a design which addresses the issues |
|
|
we have described. |
|
|
|
|
|
-> |
|
|
We describe |
|
|
the partially implemented Storm design, |
|
|
a storage system designed to cope with two problems |
|
|
raised by moving documents: Dangling links [refs stating problem], |
|
|
and keeping track of alternative versions [refs stating problem]. |
|
|
|
|
|
|
|
|
|
|
|
|
|
270 |
|
|
271 |
3. Block storage |
3. Block storage |
272 |
================ |
================ |