208 |
a versioning mechanism which is similar to OceanStore's heartbeats, |
a versioning mechanism which is similar to OceanStore's heartbeats, |
209 |
but allows the clients to download and store the pointer records |
but allows the clients to download and store the pointer records |
210 |
along with the corresponding version of a document. |
along with the corresponding version of a document. |
|
If a client caches a version of a document locally, it |
|
|
stores the pointer record along with it. |
|
211 |
Instead of having a primary replica, we search |
Instead of having a primary replica, we search |
212 |
the P2P network for current pointer records |
the whole P2P network for pointer records |
213 |
related to a document; we pick the one with |
related to a document. |
|
the most current timestamp as the version |
|
|
to show to the user by default; old versions |
|
|
remain equally accessible |
|
|
as long as |
|
|
anybody keeps a copy. |
|
214 |
|
|
215 |
An additional contribution is the Storm data model, |
An additional contribution is the Storm data model, |
216 |
an API formalizing the notion of hash-based addressing |
an API formalizing the notion of searching for data |
217 |
and content-based lookup that can be implemented |
by hash and content. The API is used by applications |
218 |
using many different P2P architectures (including |
such as browsers and implemented for each P2P network |
219 |
DHTs and the flooding broadcast search of Gnutella [gnutellaurl]_). |
accessed. Pointer records can be implemented |
220 |
The Storm data model provides a convenient interface |
on top of the Storm model, rather than separately |
221 |
to applications such as Web browsers, which then |
for each P2P network. |
|
need not worry about the P2P network(s) used to |
|
|
resolve the identifiers. Pointer records can be implemented |
|
|
on top of the Storm model, meaning that they do not |
|
|
need to be implemented separately for each time of |
|
|
P2P network. |
|
222 |
|
|
223 |
.. Like in OceanStore, old |
.. Like in OceanStore, old |
224 |
versions remain fully accessible (as long as somebody |
versions remain fully accessible (as long as somebody |
231 |
would have the benefits of semantic-free referencing-- |
would have the benefits of semantic-free referencing-- |
232 |
URIs don't have to change because of trademark conflicts |
URIs don't have to change because of trademark conflicts |
233 |
as in DNS, for example-- but go beyond the proposal |
as in DNS, for example-- but go beyond the proposal |
234 |
by Balakrishnan et.al. [balakrishnan03semanticfree]_, |
by Balakrishnan et.al. [balakrishnan03semanticfree]_ |
235 |
for replacing DNS but keeping the centralized architecture of |
to replace DNS but keep the centralized architecture of |
236 |
one Web server (or a single set of servers) maintained |
one Web server (or a single set of servers) maintained |
237 |
by the publisher of a document. |
by the publisher of a document. |
238 |
|
|
312 |
pointer records may be able to unify the namespaces |
pointer records may be able to unify the namespaces |
313 |
of different P2P systems in a similar way to hash-based identifiers. |
of different P2P systems in a similar way to hash-based identifiers. |
314 |
Similar to searching different P2P networks in order |
Similar to searching different P2P networks in order |
315 |
to resolve a SHA-1 hash, you can search different networks |
to resolve a SHA-1 hash, you could search different networks |
316 |
to find pointer records for a document. A document |
to find pointer records for a document. A document |
317 |
could be originally edited in OceanStore, then published |
could be originally edited in OceanStore, then published |
318 |
in Gnutella or a DHT-based system, using an anonymized system |
in Gnutella or a DHT-based system, using an anonymized system |
383 |
The server would publish the resulting mappings |
The server would publish the resulting mappings |
384 |
from words to block ids on the P2P network. |
from words to block ids on the P2P network. |
385 |
|
|
386 |
An index can also return additional information |
.. XXX kept out because of space constraints: |
387 |
to be placed in the hashtable along with the |
|
388 |
block id. In the example, this could be the complete |
An index can also return additional information |
389 |
metadata of the song, so that a client does not need |
to be placed in the hashtable along with the |
390 |
to download the complete audio file before being able |
block id. In the example, this could be the complete |
391 |
to show its artist, title etc. to its user. |
metadata of the song, so that a client does not need |
392 |
|
to download the complete audio file before being able |
393 |
|
to show its artist, title etc. to its user. |
394 |
|
|
395 |
The pointer functionality is trivial to implement |
The pointer functionality is trivial to implement |
396 |
*on top of* this basic model. A pointer record |
*on top of* this basic model. A pointer record |